freenode/#lisp - IRC Chatlog
Search
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."
1:06:07
jasom
IMO the only conforming thing to do with (format nil "~{~}" nil) is to return "" which is not what sbcl does. Be interesting to see if this has been discussed before
3:58:37
beach
jasom: Did you look at the chapter about garbage collection in the SICL specification?
4:42:12
mfiano
Excuse me for not paying attention to the discussions here in a couple weeks, but has anyone noticed that the recent QL dist has a broken trivia system?