freenode/#lisp - IRC Chatlog
Search
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
22:28:47
jmercouris
Josh_2: the Linux kernel, I don't know enough about it to say how it performs IPC
22:30:39
Josh_2
That's what it said no? " all communication occurs entirely within the operating system kernel."
22:31:52
Shinmera
jmercouris: When you say "sockets" the natural conclusion I come to is UDP/TCP sockets. Unix domain sockets are more special requirements.
22:32:21
jmercouris
Shinmera: Don't get me wrong, I'm not blaming you, I would have done the same, I just wanted to make sure there wasn't something I was missing
22:34:14
jmercouris
Josh_2: In a sense perhaps, as both processes are reading and writing to a file via sys calls
22:35:28
Josh_2
So I was saying wouldn't (if you used IPC) you have to use 3 different libraries or are there libraries already (I assume in C) that let you use IPC on windoge, mac os and linux
22:35:30
jmercouris
interesting, wonder what they mean by that, perhaps they mean that it is all facilitated by the kernel because of the reasons I said above
22:35:52
jmercouris
or maybe there is some special kernel facilities for domain sockets that I don't know about
22:36:26
jmercouris
Josh_2: there may be one library written in C with three implementation Linux, OSX, and Windows
22:37:58
Josh_2
Seems like a large amount of work when you could just put (let ((hostname "127.0.0.1)(port 45456))) :P
22:42:53
jmercouris
why all these weird libs? if I can't get unix domain sockets to work, I'll switch to "normal" ones
22:45:08
whoman
here is a blog post comparing windows and mac : http://blog.bfitz.us/?p=2252 -- seeing the mac ones with POSIX probably fine with linux as well.
22:46:07
whoman
...depending on use case of course. if low latency is required, the question of why the processes are seperate in the first place arises
22:47:23
jmercouris
whoman: It's definitely not an easy project, possibly a huge waste of time, but I think it's a good experience regardless
22:47:41
whoman
hmmm. i ran into that situation recently, (in concept), and decided to use ECL for the lisp and all is well
22:47:44
jmercouris
basically the lisp will be the core, and the other program, whether objective-c, c++, or c will be a "dumb" front end
22:49:08
jmercouris
I mean, it's most technically possible, but it adds lots of difficulties for nor eason
22:50:46
whoman
see now we are getting into some metaphysical existential parapsychology stuff ehh !
22:51:10
whoman
heh sorry i only assumed that your mention of cocoa means you will wrap lisp with UI
22:52:47
whoman
all you would have to do is run that, and just do lisp from there. you even got parenscript and cl-who for your user interface! oh well i tried ^_^
22:53:22
whoman
there was the deduction for solution, now its up to you to forge your own path my friend ~
22:58:34
jmercouris
well, as long as I use https://github.com/robbiehanson/CocoaAsyncSocket it'll be agnostic to whether I use unix domain sockets, or bsd style sockets
22:58:51
jmercouris
so I could start with an implementation that uses bsd style sockets, since that will be easier on the lisp side, and then try to develop some cffi bindings down the road
23:08:54
dmiles
ahah [13:54] <phoe> so if you specify STRUCTURE-OBJECT there, then you get an object without a defined type of its own.
23:10:10
jmercouris
fe[nl]ix: I'm not sure, that's just what my system tried to load when I typed in (ql:quickload "iolib")
23:14:13
jmercouris
fe[nl]ix: I got farther this time: https://gist.github.com/c3aba43f996369cec18bc317b6c7d035
23:14:38
jmercouris
seems to be just a deprecation warning, I wonder if I can adjust the flags passed to the compiler
23:15:14
jmercouris
also "lfp.h" not found, I wonder where that file even exists or what framework it is part of