freenode/#lisp - IRC Chatlog
Search
13:08:08
pfdietz
Things get pruned when they stop working, so if you depended on them and they're removed, you'd probably be in trouble regardless.
13:23:42
beach
Where in the Common Lisp HyperSpec does it say that a DEFMETHOD form is evaluated in the normal lexical environment, as opposed to the null lexical environment?
13:27:34
beach
Yes, well, we are writing a paper about MAKE-METHOD-LAMBDA and I want to get things right.
13:33:02
ogamita
Implementations indeed do it, but I don't see it specified. I guess, they don't use make-method in defmethod or defgeneric…
13:36:45
ogamita
(but I agree, it's nice that methods defined by defmethod and defgeneric be closures).
13:38:00
ogamita
"The form used with make-method is evaluated in the null lexical environment augmented with a local macro definition for call-method and with bindings named by symbols not accessible from the COMMON-LISP-USER package."
13:38:57
Bike
but the form used with make-method is a part of the result of compute-effective-method. it doesn't have a method body in it.
13:40:22
beach
Now, here is the inconsistency: http://metamodular.com/CLOS-MOP/make-method-lambda.html
13:42:10
Bike
that make-method-lambda description also redefines how call-method and sort of how make-method works but doesn't have enough detail
13:44:42
beach
It says, The generic function and method the method function will be used with are not required to be the given ones.
13:46:11
Bike
yeah, ecl and clasp incorporated that, which removes one of the objections in costanza's paper
13:47:27
beach
The other objection is that the method-class must be known so the generic function must be known, or else a method of the wrong class will be created.
13:48:14
beach
But the compiler could save the :method-class argument to DEFGENERIC just as it might save the lambda list, without creating the generic function.
17:13:42
verisimilitude
If I were building an iOS or Android program for someone, I'd try to use mocl; the main issue is they're not so free with their documentation if you don't buy it, apparently, even if you ask nicely.
17:15:46
clintm
We inquired about using mocl for Android about three or four months ago and were told it had bitrotted. Let me see if I can find the email.
17:16:20
verisimilitude
I just wanted to look at its documentation for completeness' sake in a library I've written, but didn't even receive a response.
17:18:42
clintm
Ok, so, sort of bitrotted. Constant changes to android studio, and the (lone?) developer now works at a full time job that doesn't involve mocl.
17:31:42
Xach
selling cl tools always seems like a tough row to hoe, i was hoping mocl could make it work
17:36:10
jasom
I'm curious how LTO works with clasp, since lisp lacks anything quite like a link time
17:36:25
jackdaniel
just saying, but ECL also exists, works on android and you while it has some rought edges you are physically able to fix these because it is a foss software
17:37:35
verisimilitude
I'm fortunately spared from iOS and Android development, but I'd use ECL or SBCL if I couldn't get the employer to buy mocl, yes.
17:38:34
verisimilitude
That does have me wondering, jackdaniel; mocl advertises its special declarations for linking to the native code well; does ECL have anything comparable to those?
17:40:09
jackdaniel
I don't know what are mocl's special declarations for linking, but ECL shares runtime with other C programs
17:40:39
jackdaniel
so it may be linked to other program, compiled to shared and static library and such
17:44:35
clintm
jackdaniel: Do you happen to know of any projects that try to tie the android UI with ECL? I wouldn't expect it to be part of ECL itself, but I looked around when we were evaluating our options and didn't find much in the way of projects, examples, or the like that did anything with the UI.
17:44:54
jackdaniel
it doesn't have Apple's Xcode integration, but it allows defining lisp functions which are called like other C functions
17:45:44
jackdaniel
EQL5-Android project developed it further and has great demos with user interface
17:45:55
clintm
Oh yea, I think I messed with that on one of our test devices! It worked quite well, as I remember.
17:46:52
clintm
Ohh, right, is that the one that needs the specific version of the ndk? Not saying that's a problem or anything, it's just been three or four months since I was poking at this.
17:47:31
jackdaniel
the one I wrote requied specific ndk version because the newer one had some bug, but it was around 2y ago, I would suspect it should work now
17:48:03
jackdaniel
and if not pull requests are welcome and source is available (if it is ecl fault)
17:48:15
clintm
Hrm, yea, I built and messed around with that. I may have to dig into it again - I can't remember why I passed on it.
17:48:16
jackdaniel
here are screenshots: https://gitlab.com/eql/EQL5-Android/tree/master/screenshots
17:50:06
clintm
Yea, right! I built the skoban and repl examples, installed and ran them and they worked as advertised as I remember. Ok, now I'm really curious. Time to shave some yaks and set it up again.
17:50:11
jackdaniel
the most notable drawback with ECL on android is that usually you are forced to use bytecompiler at runtime (nothing technical, devices just usually doesn't have gcc), but you may load precompiled libraries
17:50:50
jackdaniel
and the second drawback is generic function dispatch performance. we plan to address that after upcoming release
17:50:57
clintm
I don't remmeber that being a problem, but I also don't remember doing anything special because of it.
17:58:56
jackdaniel
we know how to improve it (thanks to beach papers and clasp team experimentation)
17:59:55
jackdaniel
I'd say drmeister, but there are more developers who do teremendous job with it (for instance Bike)
18:07:12
Bike
i'd like to see about inlining method bodies themselves so it's like a real jit, but that's a lot of work
18:07:40
drmeister
Yeah - it's not all me anymore. Bike is doing a tremendous amount - Cleavir was written by beach. kpoeck has been fixing lots of bugs. The list goes on.
18:11:22
Bike
i guess rather than full method bodies it's accessors really, or maybe gfs more generally
18:13:14
Bike
it would be pretty cool for accessor calls within methods to be turned into inline memorhy accesses
18:40:56
pfdietz
another-user: that is, if you're using one the standard equality functions (eq, eql, equal, equalp), so it can build a hash table for membership testing.
18:42:08
another-user
pfdietz: yeah, i would like to get "012" from (loop for i from 0 to 2 collect (format nil "~a" i))
18:42:09
verisimilitude
The first thing that comes to mind is collecting into a list and then using COERCE, another-user.
18:42:26
pfdietz
Not directly, but you can set up an extensible character vector with a fill pointer and use vector-push-extend.
18:43:13
pjb
another-user: (coerce (loop for i from 65 to 74 collect (code-char i)) 'string) #| --> "ABCDEFGHIJ" |#
18:43:36
pjb
another-user: but actually: (with-output-to-string (out) (loop for i from 65 to 74 do (write-char (code-char i) out))) #| --> "ABCDEFGHIJ" |#
18:44:04
pjb
another-user: or: (with-output-to-string (out) (loop for i from 65 to 74 do (format out "~D " i))) #| --> "65 66 67 68 69 70 71 72 73 74 " |#
18:45:12
verisimilitude
I always use *STANDARD-OUTPUT* as the symbol bound with these types of macros.
18:45:39
pjb
If you do a single collection at a time, yes. But giving another name let you collect several strings at once.
18:45:49
verisimilitude
Then you don't introduce an unnecessary symbol into the system and you can type less.
18:46:26
verisimilitude
I've yet to run into a nesting situation such as that, pjb, but that would be an example of when not to necessarily do it, yes.
18:47:42
pjb
(block nil (with-output-to-string (odd) (return (values (with-output-to-string (even) (loop for i from 65 to 74 do (write-char (code-char i) (if (oddp i) odd even)))) (get-output-stream-string odd))))) #| --> "BDFHJ" ; "ACEGI" |#
19:04:57
verisimilitude
I suppose I may work more on my ACUTE-TERMINAL-CONTROL and clean my CL-ECMA-48 of unnecessary symbols a tad before the year's end, seok.
19:08:43
drmeister
I'm implementing compile-file-parallel - it compiles AST's in serial and then tosses the AST->native code compilation into threads. I'm seeing contention and so I'm exploring ideas on how to track down the source and fix it.
19:10:00
drmeister
Clasp's stacks are pretty deep and we blow through the bullsh*t 512 frame limit of Xcode's Instruments - what a load!
21:18:11
jasom
it won't show you directly, but you should see threads spending a lot of time in lock acquisition
21:18:55
jasom
if you don't have a good one, just break all threads into the debugger randomly a dozen times and see what locks are contended (if contention is more than half the problem, you should see 5 or more of the same lock contended)
21:19:39
jasom
drmeister: not easy to tell from that graph; depending on the lock implementation you get very different CPU profiles for contention
21:20:03
jasom
e.g. some userspace mutexes will spin a few times before blocking, others will always do a syscall even in the non-contended case
21:20:53
jasom
shouldn't need to look at backtraces; the lock acquisition code should be on the top of the stack when waiting
21:22:07
drmeister
I mean when I use dtrace I get lots of backtraces and the lock acquisition should be at the top of the stack in many of them.
0:26:36
jasom
ACTION is secretly hoping that the issue will be the GC stopping the workd and drmeister will spend the next 6 months writing a state-of-the-art concurrent GC for clasp
1:02:31
verisimilitude
I usually make that mistake as well, didi, unless I recently made it and recall.
1:03:07
jasom
I also think that SBCL is wrong about ~{~} with nil as the argument, because the spec says "If before any iteration step the list is empty, then the iteration is terminated."