freenode/#lisp - IRC Chatlog
Search
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.
19:23:20
emaczen
will anyone explain some details about the complexities of writing your own concurrency especially via (reduce (map ...))?
19:23:20
Colleen
emaczen: beach said 9 hours, 22 minutes ago: You might want to look at Amdahl's law: https://en.wikipedia.org/wiki/Amdahl%27s_law
19:36:38
emaczen
I understand the basics of Amdahl's law, I would like to know more generally about why my highly parallelizable program is not faster than running serially. How much overhead is bt:make-thread and bt:join-thread?
19:53:52
Bike
borei: you tell it it's a simple array, but not what the element type of that array is. do you know? like, is it a general array, or a string, or could it be either?
19:56:58
emaczen
Bike: https://pastebin.com/mHAW5cjz -- I made a new paste with slightly different code
19:58:03
Bike
borei: then you can write (the (simple-array (simple-array single-float (4)) (*)) (elements matrix))
19:58:10
emaczen
Bike: my paste from last night was from a custom linked-list data-structure, so to remove all doubts about my customized code being the reason that the code is slow (which it does probably add to that fact since there is overhead with CLOS), this paste is just a plain old lisp list.
20:01:46
Bike
okay, so with cores of four, say, what you're going to do is make a list of four elements, each of which consist of 2500 elements.
20:02:42
Bike
So obviously it's not going to be much better than making a list of ten thousand elements. In fact with the threads it is probably going to be worse.
20:03:41
Bike
The task is kind of fundamentally flawed, I think. Consing the list is probably going to be more expensive than arithmetic.
20:04:40
emaczen
Bike: This is an over simplistic test scenario. In general I have a lot of programs that could be map-reduced
20:05:00
Bike
i'm sure, but i'm just telling you that amdahl's law is telling you this isn't going to work.
20:05:28
Bike
Do you know how append works? It makes new lists. You're doing way more consing in the parallel version.
20:05:57
Bike
lparallel has implementations of map reduce. i haven't used it myself but it looks pretty robust.
20:06:50
_death
maybe instead of just timing it, profile it so you can see where time is spent.. and do this with the "real" code
20:17:32
emaczen
Bike: I create the partitions in each thread now, and did not reduce and it is faster
20:40:48
Bike
They are on your implementation. Another implementation could hypothetically not have them equivalent, though I wouldn't worry about it. Try (upgraded-array-element-type '(simple-array single-float (4)))
20:41:43
Bike
since your specified element type of (simple-array single-float (4)) upgrades to T, the two types are equivalent.
20:56:33
Bike
does #s syntax for structures not work if :type is specified? I thought it did, but it doesn't on SBCL.
21:41:23
dmiles
speaking of structure type vs :type ... is what would be :type that would yiled the same type as omitting it? (i dont mean a NIL) i mean would it be structure-object ?
21:44:03
dmiles
this is for my own impl.. but i'd like to align with at least some other impl somewhere
21:45:55
dmiles
"defined by the implementation to be appropriate." so wondering has anyone ever came up with "appropriate."
21:50:20
dmiles
oh but why meant to care (i forgot to say it) is i want to have at least something like "structure-object" be somewhat predictable around what people have expected
21:55:15
Bike
well, in a few places it specifies that so-and-so works if :type is specified or not specified.
21:55:25
phoe
"If no :type option is involved, then the structure name of the including structure definition becomes the name of a data type, and therefore a valid type specifier recognizable by typep; it becomes a subtype of the included structure."
21:55:49
phoe
so if you specify :TYPE option at all, then some parts of DEFSTRUCT just don't work anymore.
21:56:26
phoe
so if you specify STRUCTURE-OBJECT there, then you get an object without a defined type of its own.
21:56:42
Bike
defstruct kind of does two different things that are similar enough that they mashed them together.
21:57:21
phoe
Yes, it a) defines structure-objects, b) defines a series of accessors and copiers and what not for accessing data structured into a particular data type that already has a type.
21:57:43
phoe
which are list and vector in the standard, but an implementation is permitted to use other DSes as well.
22:07:35
jmercouris
Shinmera: I've been looking around, and it seems Usocket does not support unix domain sockets and is meant primarily for networking, am I correct?
22:09:11
jmercouris
I did find IOLib which definitely supports Unix sockets, but (ql:who-depends-on "iolib/sockets") returns nil
22:14:41
TMA
bsd style sockets are other name for (a) tcp sockets (b) the whole socket(2) syscall ecosystem
22:18:15
TMA
jmercouris: there are two hard problems in programming: naming things, cache invalidation and off-by-one errors
22:19:22
jmercouris
so many people misusing terms as well, that I'm not sure what the meaning of some words is anymore
22:19:45
TMA
(I have read that winsock.dll implements "bsd sockets" on windows but it does not implement AF_UNIX domain sockets at all)
22:19:47
jmercouris
if I can't get iolib to work, I'll have to settle for usocket, as much as I would like to not do that
22:22:56
jmercouris
rme: so you're thinking about putting in support for what precisely? unix domain sockets as an extension to CCL?
22:23:27
rme
If Windows ever supports the AF_UNIX address family, it would be good to add support for that. Windows already supports the AF_INET address family.
22:24:16
jmercouris
Josh_2: I'm interested in IPC, and yes, it is possible with usocket and those types of sockets, but I really don't like the idea
22:24:48
jmercouris
Josh_2: there is only one computer involved, and two processes are communicating via a special type of file