freenode/#lisp - IRC Chatlog
Search
7:11:23
smokeink
krwq: (declaim (optimize (debug 3))) (let ((v1 2) (v2 3)) (incf v2) (break) ) ; krwq can you eval in frame and get v1 or v2's value?
7:15:07
krwq
yes, but I'd put (declaim (optimize (debug 3))) in your .sbclrc or whatever config file you use
7:16:28
smokeink
ok, I already had (declaim (optimize (safety 3) (debug 3) (space 0) (speed 0))) in my .sbclrc , but I can't evaluate v1 or v2 in frame... It always says they're unbound
7:39:52
pjb
Try with: (declaim (optimize (debug 3))) (let ((v1 2) (v2 3)) (incf v2) (break) (values v1 v2))
7:41:18
beach
smokeink: I think that's what I said before. The compiler eliminates variables that are not live, independently of the scope defined by the programmer.
7:42:05
beach
Suppose (g y) signals an error. The stack frame of this expression no longer contains X because it is no longer live.
7:42:35
pjb
Even if the variable was live, it could be eliminated, eg. if it is used only once, and side effect order wouldn't be changed by replacing its use by its initial expresion.
7:44:00
smokeink
it's good to know that one can add a (values v1 v2 ... ) at the end, then the (break) can be put anywhere in the let body
7:44:38
beach
smokeink: If the LET is in a context where its values are not needed, the compiler can remove those too.
7:44:48
phoe
which might be a bit overkill to work with vectors since it's meant for any-dimensional arrays
7:45:26
phoe
smokeink: in general, the compiler is free to optimize everything that doesn't affect the final outcome of the function.
7:46:27
phoe
if you want fast and optimized code, then you want the compiler to be able to optimize the hell out of it
7:46:47
phoe
if you want debuggability, you want the compiler to probably not optimize a single thing
7:47:27
beach
whoman: The compiler is obviously only allowed to perform semantics-preserving transformations.
7:48:33
TMA
whoman: semantic-preserving does not entail preserving the choices made under undefined behavior though
7:51:43
beach
phoe: Not quite that easy. It is entirely possible that the implementation decides to define behavior that is labeled as undefined in the standard. If so, it kind of promised to preserve the semantics of that behavior.
7:53:22
emaczen
pjb: is (reduce fn (mapcar (compose #'bt:join-thread (lambda (piece) (bt:make-thread ....))))) the correct form composition for map-reduce?
7:55:04
phoe
There's been a series of discussions that BT:JOIN-THREAD's return value is not meant to be used as anything meaningful, but I've yet to see a free implementation that doesn't return the thread function's return values in that case.
8:02:21
emaczen
I'm just testing out a simple map-reduce with generating a range of numbers, splitting the range into 4 equal partitions since I have 4 cores, and then evaluating. It is actually a lot slower...
8:04:49
phoe
and it's harder to screw up with LPARALLEL than it is by rolling out your own implementations.
8:06:06
emaczen
Using (time ...) the only difference I see between sequential code and my threaded map-reduce code, is that the sequential code uses 0.2% of the CPU and the threaded code uses 77% of the CPU
8:06:53
emaczen
phoe: my code is not much more complicated than that (reduce fn (map ..)) form I showed earlier
8:09:03
whoman
if you want to do it your way, why insult the vets giving you real world wisdom and making them watch you go through what they went through
8:10:33
whoman
(just curious, does it matter if the list is linked in both ways, if the map goes one way?)
8:11:31
emaczen
whoman: not sure if it is necessary but I used the previous link for programming ease
8:12:38
whoman
they can be mutated/destructed during traversal too, its cool =) just wondering if an existing map could walk it
8:16:31
emaczen
whoman: Actually I don't think it needs to be doubly-linked, however I made a mistake in lower levels of my code so I think I have to
8:21:30
whoman
i stay frozen solid unmovable due to immobilizing fear of mistakes. since when i started life... =P
8:44:32
smokeink
Let's say I have this fib function that breaks when the parameter n equals 2 , https://stackoverflow.com/questions/27889989/stepping-in-sbcl-from-within-the-debugger?rq=1 How to proceed to STEPPING , right after the (break) , without using slime's Return From Frame" (R) and manually typing (fib 2) ?
9:28:12
ludston
emaczen: doing things in parallel is pretty easy. The tricky part is the synchronization afterwards.
9:30:45
ludston
That is, if you follow a simple rule; don't ever modify state that is being referred to by more than one thread. Things like mapreduce are handy abstractions that people have invented for following this rule.
9:40:26
dim
doing things concurrently is easy when it makes sense that every one is only minding their own business, computer beings involved or not ;-)
9:42:41
ludston
Doing trickier things than that is usually a bit of a mine field for other people trying to work with your code. (Imho this is why Google based their parallelism on mapreduce-> it means that Google devs didn't have to worry about the minefield that is trying to guess which state might be modified by multiple threads the first time that they are looking at some code)
10:01:17
beach
::notify emaczen You might want to look at Amdahl's law: https://en.wikipedia.org/wiki/Amdahl%27s_law
10:38:59
smokeink
Why is sbcl's core image (27mb) so huge in comparison to Corman CL's (1.5mb) ? How is it that FreeBasic can create binaries as small as 120kb (that can portably plot gfx onto a GUI window ) ?
10:40:52
dim
compare with Go binary images maybe, or those produced by something that doesn't link/require libc at runtime
10:41:28
beach
smokeink: The Common Lisp runtime is more complex than (say) that of C, because CLOS needs the compiler and there is the garbage collector of course.
10:41:37
dim
IME most small executable binaries are small because they just rely on the right version of libc being there at runtime
10:42:11
beach
smokeink: Having said that, I think someone should create a Common Lisp implementation where most of the code is in a shared library.
10:45:25
jackdaniel
fwiw that's how ECL graphical application works on android – libecl is accessed via jni wrapper from java
10:51:58
jackdaniel
dmiles: all functions are (unless they are bytecompiled, in that case you have to use cl_funcall)
10:52:50
jackdaniel
there is a calling convention for functions with &optional, &key etc as well as for closures
10:54:12
dmiles
very nice.. (despite working on wam-cl i have quite a bit i plan being done with ECL from SWI-Prolog's new LibFFI)
10:56:52
jackdaniel
fittestbits: I have good news for you, I've fixed the ticket you reported yesterday (will push in a minute)
11:49:24
scymtym
fe[nl]ix: could you make a fiveam release? i think the accumulated changes justify one
12:02:54
scymtym
fe[nl]ix: maybe getting rid of asdf's "recursive use of test-op" before the release would be good? or immediately after the release, depending on how you operate w.r.t. these things
18:21:36
pjb
fourier: indeed, despite being a commercial venture, mocl doesn't seem to benefit from a lot of resources. Of course, since my bug reports were dead letter, I didn't renew my license.
18:22:02
pjb
fourier: you would have to pay for a source license, and debug it yourself. At that price, I find it preferable to work on clicc.
18:23:00
pjb
fourier: that said, if you can accept that it's only an implementation of a strict subset of CL, you can consider that it works nicely enough for the intended purpose.
18:24:12
pjb
fourier: of course, since you still have to implement the UI in kotlin or swift, and since you can compile kotlin on iOS, the question is whether it's worth the trouble to use CL for the core of the application, given that you won't be able to use random CL libraries with it (basically you have to write subset-CL code from scratch).
18:25:24
pjb
fourier: you can have a look at the #-mocl in com.informatimago to evaluate if that would be a problem for you.
18:26:03
pjb
Again, while I'm dissatisfied, it can meet your requirements, so I wouldn't discard it without an evaluation.
18:27:03
pjb
One main problem however, is that a lot of mobile applications actually do not contain any core code! Instead they're just UI, tunneling information from the backend server to the screen…
18:28:12
pjb
So unless you have an application that actually does something locally (eg. that can be useful while not being connected ot the Internet), it may be not that useful.
18:31:55
pjb
Sure, if you have this core computation. But this is not the case in 75% of mobile applications.