<pfdietz>
I saw that last week when I entered "Common Lisp" into google news search.
<pfdietz>
BTW, they were recently hiring Common Lisp people. May still be looking.
thallia has joined #lisp
<krwq>
I wonder if they've tried running it on itself
<pfdietz>
Dogfood!
Pixel_Outlaw has quit [Quit: Leaving]
sjl has quit [Ping timeout: 248 seconds]
quazimodo has quit [Ping timeout: 276 seconds]
Pixel_Outlaw has joined #lisp
dmiles has joined #lisp
Pixel_Outlaw has quit [Client Quit]
antonv has joined #lisp
<antonv>
hi all
<whoman>
heh
<antonv>
can anyone advice for a fast method for reading / writing large plists?
rumbler31 has joined #lisp
<antonv>
standard printer and reader are very slow
<antonv>
if there was a subset of their functionality (say without custom macro characters) working fater, that would be good
<krwq>
have you tried something like: (loop for (name val) on '(:a 123 :b "dsafs") do
<krwq>
(format t "(~s ~s)~%" name val))
<krwq>
I don't know where or how do you want to write them
dmiles has quit [Ping timeout: 240 seconds]
<antonv>
krwq: that's what I do now
<whoman>
i dont think format would be fast
<antonv>
and read them with cl:read
thallia has quit [Ping timeout: 276 seconds]
<antonv>
my data are plists, containint only strings, keywords and numbers\
shka has joined #lisp
thallia has joined #lisp
<antonv>
what interests me more is reading
<antonv>
writing is secondary
<pierpa>
it's hard to imagine you can beat PRINT and READ at this.
<antonv>
pierpa: turns out READ is to generic to be fast
<krwq>
you might want to try different data structure than plist if that's possible
<antonv>
krwq: how would that help?
stacksmith has joined #lisp
<krwq>
linked lists are slower in general and if you know the data type that should help
<whoman>
are you printing the whole plist or each item ?
<pierpa>
do you have any idea about what is slow? maybe parsing the numbers?
smokeink has joined #lisp
<pierpa>
can you use vectors instead of lists? reading vectors with included length prefix should be faster than reading a list.
<antonv>
whoman: whole plist
<pfdietz>
Are you trying to print this so it's human readable?
<antonv>
pierpa: my guess is that reading atoms is slow
<pfdietz>
Or just to SOME serialized form?
fikka has quit [Ping timeout: 240 seconds]
<antonv>
pfdietz: yes, for readability. But I'm ready to give it up for good speed improvement.
<pfdietz>
cl-store does serialization in a form that's optimized for speed and compactness, not human readability, if that's helpful.
<antonv>
pfdietz: let me check it...
<pfdietz>
Which Common Lisp are you using, btw?
__rumbler31 has joined #lisp
<antonv>
I was looking for somethe serialization librarty, but had impression that none of them is fast
<antonv>
CCL
<antonv>
byt I tried other CLs, their readers are slow too
<pfdietz>
Hmm.
<pierpa>
most implementation have FASL writers and readers
<pierpa>
if you don't need to be portable...
<antonv>
pfdietz: interesting idea
<antonv>
I'm checking cl-store speed now...
<antonv>
pfdietz: how whould one store some data in FASL?
<pfdietz>
That was pierpa talking about FASLs.
<pierpa>
and the answer is: it depends. It's implementation dependent
<Bike>
no it isn't. compile-file something with a plist in it, bam, stored
<pfdietz>
When you benchmarked the reader, were you reading from a file, or from a string?
<antonv>
pierpa: sorry
<whoman>
better data structure ftw
fikka has joined #lisp
<Bike>
yeah "fast" and "plist" are kind of separated in my mind
<antonv>
pfdietz: from file
<pfdietz>
It would be interesting to see where the time is being spent.
Jen has quit [Ping timeout: 240 seconds]
__rumbler31 has quit [Ping timeout: 248 seconds]
<pfdietz>
What effect the external format had on it, too.
JenElizabeth has joined #lisp
beach` is now known as beach
<pierpa>
to see where time is spent could also try to compare the time needed for reading the same data written as a vector with length prefix #12349556(k1 v1 ...)
<krwq>
is there a way to change initform in the derived class without redefining the slot?
<Bike>
well, you partially redefine it.
<krwq>
Bike: so just add this one slot which changes?
<Bike>
like, if your slot is called foo, you can just have (foo :initform blablabla) and itll keep the accessors and stuff from parent classes.
<antonv>
cl-store writes verly slowly
<antonv>
slower than my current format approach
<antonv>
and finally fails with "memory allocation request failed"
<antonv>
pierpa: lenght prefixed vectors - is that starndard synax?
<pierpa>
[ and ] are reserved for user character macros, so yes, you can use them
nowhereman_ has joined #lisp
antonv has quit [Read error: Connection reset by peer]
nowhere_man has quit [Ping timeout: 256 seconds]
Guest99623 has joined #lisp
rumbler31 has quit [Remote host closed the connection]
fikka has quit [Ping timeout: 248 seconds]
fikka has joined #lisp
thallia has quit [Ping timeout: 268 seconds]
<beach>
jasom: Are you referring to a real debugger (where you can set breakpoints, step by form, trace, examine data, etc), or what we habitually call a debugger but that really isn't?
<beach>
jasom: In McCLIM, we have one of the latter type already.
thallia has joined #lisp
dmiles has joined #lisp
<beach>
jasom: And I have a specification for one of the former type, but it will require support from the implementation that most implementations may not have yet.
epony has quit [Remote host closed the connection]
Bike has quit [Quit: Lost terminal]
epony has joined #lisp
<krwq>
is there any way to get self reference in the slot's initform?
<beach>
No.
dmiles has quit [Ping timeout: 240 seconds]
<krwq>
beach: fair enough, thanks
<beach>
Use an :AFTER method on INITIALIZE-INSTANCE.
<krwq>
beach: sounds good, thanks
epony has quit [Remote host closed the connection]
<beach>
If you don't want to have a slot writer (which often happens to me), then you can use REINITIALIZE-INSTANCE instead.
pierpa has quit [Quit: Page closed]
<beach>
I mean, you call REINITIALIZE-INSTANCE inside the :AFTER method on INITIALIZE-INSTANCE.
saturn2 has joined #lisp
<krwq>
beach: can't I use slot-value?
<beach>
You could.
<beach>
I never do, because I consider slot names as being implementation details.
<krwq>
beach: so what does reinitialize-instance do?
<beach>
... whereas slot accessors and :INITARGs are part of the protocol.
<krwq>
beach: not sure why do you think this way but I barely know CLOS
<beach>
It allows you to split up the initialization process.
<beach>
It has nothing to do with CLOS. It is the same in every language. Slots (or fields, or data members) are implementation details that may change in the future.
<krwq>
beach: I think I'll pass with this for now, slot-value works - I'll likely get to that point where I understand the advantage
<krwq>
beach: but passing for now
<beach>
Accessors are part of the documented protocol (or interface, as most other languages call it).
orivej has quit [Ping timeout: 240 seconds]
<krwq>
beach: I see - this is meant to be implementation detail, I do not want any accessor here
<beach>
You typically still want an accessor. It is what is called an "internal protocol", i.e. even in your module implementation code, you want to be somewhat modular.
<beach>
Here is another reason: It is possible that in your implementation, SLOT-VALUE, (SETF SLOT-VALUE) etc. are slower than slot accessors.
<beach>
Not in SBCL though, which basically converts SLOT-VALUE with a constant slot name to a kind of slot reader.
<krwq>
beach: do you mean lisp implementation or library implementation?
<krwq>
ok clarified
raynold has joined #lisp
<krwq>
beach: I might gradually get to the better design but haven't thought through the internal protocl yet
<beach>
I mean that your Common Lisp may have to do more work with slot-value, because it first has to figure out where the slot is stored in the object, given the class of the object and the name of the slot. This procedure can easily be bypassed in a slot accessor, and less easily with slot-value.
<krwq>
beach: I see - that's fine for now, that's not going to be a bottleneck here
<beach>
Sure, you don't think of that in the beginning. But it is good to prepare for them by not using slot-value or with-slots.
<krwq>
with-slots as well? that can easily be fast, shouldn't it?
<beach>
It's easy. Just stick a :reader or :accessor in there with a name that is not exported.
<beach>
WITH-SLOTS expands to slot value.
<beach>
So, stick a reader or accessor in there, use those to access the slot, or use WITH-ACCESSORS where you would otherwise use WITH-SLOTS.
<beach>
Not that hard.
<beach>
In my code, the name of the slot serves only two purposes: The primary purpose is so that when the DEFCLASS form is re-evaluated, the Common Lisp implementation knows that it is the same slot as before. The secondary purpose is so that the Common Lisp implementation knows that when a slot is mentioned in both some class and some subclass, I meant for it to be the same.
<beach>
The latter case is unusual though.
<whoman>
^_^
Guest99623 has quit [Read error: Connection reset by peer]
djinni` has quit [Ping timeout: 260 seconds]
<krwq>
beach: I ocassionally iterate on the slots in the macrolet
<beach>
Using the slot names? I am sorry to hear that.
<krwq>
beach: yep but no problem with doing that with accessors too
<beach>
If I am really interested in the slots, I would use that one ↑
<beach>
That way, I don't have to mention slot names explicitly, and the code continues to work even when slots are added or removed.
<krwq>
beach: I had hard time with that when the library I used added some slots I didn't want with the metaclass
<krwq>
beach: I only needed some of them
<beach>
That is when the pairs initarg/accessor are useful. I often use a registration mechanism so that the relevant pairs are available by a call to a generic function.
<beach>
For example, when I save an object to a file, it is saved as [<class-name> :initarg1 value1 :initarg2 value2...]
<beach>
That way, I can reload the file even after my implementation has changed, so that some slots are added or removed.
<krwq>
beach: how do you do that?
<krwq>
beach: by hand or have some fancy metaclass
<beach>
The SAVE-INFO generic function returns a list of those pairs.
<beach>
The macro DEFINE-SAVE-INFO defines those relevant pairs for each class.
<beach>
All I need to do in order to read an object saved that way is a reader macro on #\[ that does (apply #'make-instance (read-delimited-list ...)).
<krwq>
beach: but it still requires that :initarg hasn't changed right?
<beach>
That would be part of the documented external protocol, so it had better not change.
<krwq>
btw, how far are you to implementing SICL?
<beach>
Most of the code is there. I am working on the bootstrapping procedure. Also, Bike is working on Cleavir, and probably heisig as well pretty soon. Right now I am working on indentation in the editor.
<krwq>
beach: what editor do you have? I only have tried clim-listener so far
<krwq>
beach: or do you write some emacs mode
<beach>
Well, Climacs already exists, and I am working on version 2 of it, which is planned to have much better functionality for editing Common Lisp code.
<beach>
No, not Emacs. Pure Common Lisp.
<krwq>
nice, are you planning to implement clim over emacs buffer too?
<beach>
I don't understand the question [it's too early in the morning].
<krwq>
clim can display on everything and I assume your implementation is using clim interface
fikka has joined #lisp
<krwq>
so you could technically display everything in emacs
<krwq>
and have two versions of climacs
<krwq>
as emacs mode and standalone
<krwq>
that should have better adoption
<beach>
I don't see how you could use Emacs with CLIM, other than in very simple ways.
epony has quit [Remote host closed the connection]
<krwq>
beach: what's not supported? it can display pictures
<beach>
But I am not interested in programming in Emacs Lisp.
<beach>
The plan is to propose a set of tools for Common Lisp programming that are an order of magnitude better than the Emacs-based tools we have today.
<beach>
So, using Emacs with those tools would kind of defeat the purpose.
<krwq>
beach: fair enough but if you've proved the point of clim universality by making it work with emacs it would gain in popularity much faster and likely gain contributors faster
<krwq>
don't want to sidetrack or anything but that sounds like a nice hackathon project or something you could give to a student
<beach>
Yes, but that is not my primary goal. My primary goal is to have a comfortable Common Lisp-based environment, and to have my effort to create it count as research.
<beach>
As I often say, it is fine with me if I end up being the only user of those tools.
<krwq>
good point but note that if you did it this way then you could reverse the dependencies by making emacs work with clim as well and those emacs modes could eventually work with climacs
<krwq>
so you'd consume many years of work into climacs
<krwq>
something to think about - do what you like though :)
<beach>
Yes, well, someone who is interested in working that way could do it. I'll work on what I am good at. In particular the hard parts that require fresh research.
EvW1 has joined #lisp
<krwq>
are you using climacs daily?
<beach>
No, because (first) Climacs is not as good as Emacs, even for Common Lisp programming. This is why I am working on Second Climacs.
<krwq>
beach: I'll be interested to test it once it is usable and fairly convenient. I write most of my stuff in CL either way
<beach>
Thanks. It may be a few more months before I have something to demonstrate.
<krwq>
beach: for me some easy way to work with s-exp and decent debugging is a must
<beach>
Of course.
<smokeink>
*decent debugging*
<smokeink>
speaking of decent debugging, I've found this overly complicated https://www.youtube.com/watch?v=q_ARlVo-J5Q how come it's so difficult to access the local vars during debugging?? Is this feature really that unimportant ?
dmiles has joined #lisp
<krwq>
I'm seeing clim has a lot of potential, currently feel like some defaults look ugly but each time I try it it feels much better and things like clim-debugger are proving it
<krwq>
smokeink: I find when I use (break) or short functions the experience is all right
<krwq>
and (declaim (optimize (debug 3))) ofc
<smokeink>
you can break and display the local vars, but what if you need to interact with them? You need to play around with them, to see where they fail to behave as you were expecting..
<beach>
krwq: Yes, McCLIM is steadily improving, thanks to jackdaniel and several recent contributors. I am very happy with the way things are going.
dmiles has quit [Ping timeout: 260 seconds]
Patternmaster has joined #lisp
SaganMan has joined #lisp
<krwq>
smokeink: you can eval in frame in slime
<beach>
smokeink: It is hard, because Common Lisp implementations take advantage of the freedom the Common Lisp HyperSpec give them to optimize lexical variables.
<krwq>
smokeink: just put (break) and read C-c C-h when debugger shows up
<beach>
smokeink: Information about the location, type, etc, of lexical variables must be made available at runtime in order for a debugger to use this information. And it must be done in a way that does not hamper performance.
damke has quit [Read error: Connection reset by peer]
SaganMan has quit [Client Quit]
<beach>
For one thing, the compiler typically reduces the scope of lexical variables. They are not kept around after their last reference. So the programmer may want to examine the variable, but the compiler has eliminated it at that point.
<beach>
Take this one: (let ((x ...) (y ...)) (f x) (g y))
<beach>
Suppose (g y) signals an error. The stack frame of this expression no longer contains X because it is no longer live.
<smokeink>
k
<beach>
Different problem: (let ((x ...)) (declare (type fixnum x)) (f x) (g x)). Suppose (f x) signals an error. The programmer uses the debugger to alter X so that it is a string instead of a fixnum. The call to G may then fail by having your Common Lisp crash.
<beach>
So, a good debugger must disallow such modifications of values of lexical variables.
damke has joined #lisp
<beach>
The technique suggested in that video slows down the code a lot, so it is only acceptable as a temporary solution.
<smokeink>
okay: my point is maybe pandoric macros can be of help, perhaps a less cumbersome solution using pandoric macros is possible - it's an interesting thing to research
fikka has quit [Ping timeout: 248 seconds]
python476 has joined #lisp
Trystam has joined #lisp
fikka has joined #lisp
LocaMocha has joined #lisp
Tristam has quit [Ping timeout: 276 seconds]
Trystam is now known as Tristam
shifty has quit [Ping timeout: 256 seconds]
windblow has quit [Remote host closed the connection]
fikka has quit [Ping timeout: 256 seconds]
windblow has joined #lisp
fikka has joined #lisp
dmiles has joined #lisp
ludston_ has quit [Read error: Connection reset by peer]
shka has quit [Quit: Konversation terminated!]
ludston has joined #lisp
EvW1 has quit [Ping timeout: 255 seconds]
fikka has quit [Ping timeout: 276 seconds]
Oladon has quit [Quit: Leaving.]
windblow has quit []
fikka has joined #lisp
quazimodo has joined #lisp
fikka has quit [Ping timeout: 248 seconds]
fourier has joined #lisp
rumbler31 has joined #lisp
cpape` has joined #lisp
fourier has quit [Ping timeout: 240 seconds]
rumbler31 has quit [Ping timeout: 248 seconds]
cpape has quit [Ping timeout: 256 seconds]
flamebeard has joined #lisp
<phoe>
pandoric?
cpape`` has joined #lisp
fikka has joined #lisp
cpape` has quit [Ping timeout: 240 seconds]
vlatkoB has joined #lisp
Karl_Dscc has joined #lisp
fikka has quit [Ping timeout: 248 seconds]
Arcaelyx_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<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?
pillton has quit [Quit: ERC (IRC client for Emacs 25.3.1)]
cpape``` has joined #lisp
<krwq>
yes, but I'd put (declaim (optimize (debug 3))) in your .sbclrc or whatever config file you use
cpape`` has quit [Ping timeout: 256 seconds]
<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
Karl_Dscc has quit [Remote host closed the connection]
fikka has joined #lisp
cpape```` has joined #lisp
openthesky has joined #lisp
cpape``` has quit [Ping timeout: 256 seconds]
fikka has quit [Ping timeout: 276 seconds]
vyzo has quit [Remote host closed the connection]
fikka has joined #lisp
cpape```` has quit [Ping timeout: 256 seconds]
fikka has quit [Ping timeout: 255 seconds]
<pjb>
smokeink: since they're not used, they're not needed, so they're not generated.
<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.
cpape has joined #lisp
<beach>
Take this one: (let ((x ...) (y ...)) (f x) (g y))
<beach>
Suppose (g y) signals an error. The stack frame of this expression no longer contains X because it is no longer live.
<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.
<phoe>
the compiler is free to rewrite it like that or something
<phoe>
basically put the BREAK after the LET
<beach>
pjb: Very good point.
<emaczen>
How do you get the size of a vector (max size of the fill-pointer)
<phoe>
...I probably screwed up the parens, (let ...) (break) <= like this
<pjb>
(array-dimension v 0)
<pjb>
or (elt (array-dimensions v) 0)
fikka has joined #lisp
<whoman>
erc lets us paredit in irc
<beach>
emaczen: Do you want to ignore the fill pointer or take it into account?
<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
<emaczen>
beach: array-dimension is what I wanted
<phoe>
emaczen: also #'ARRAY-TOTAL-SIZE
<pjb>
Yes, works for vectors too.
<beach>
smokeink: If the LET is in a context where its values are not needed, the compiler can remove those too.
<phoe>
which might be a bit overkill to work with vectors since it's meant for any-dimensional arrays
<beach>
smokeink: (progn (let ((x ...) (y ...)) ... (values x y)) (f)) for example.
<phoe>
smokeink: in general, the compiler is free to optimize everything that doesn't affect the final outcome of the function.
<phoe>
which means return values, and side effects.
<beach>
smokeink: It is VERY HARD to predict what the compiler will do.
<whoman>
...thats not a good thing, beach
<phoe>
whoman: depends on the compiler
<beach>
whoman: What? That it is hard to predict what the compiler will do?
<phoe>
if you want fast and optimized code, then you want the compiler to be able to optimize the hell out of it
<whoman>
ah true, didnt see 'if it doesnt affect outcome..'
<beach>
whoman: Unfortunately, that's a necessary side effect for good performance.
<phoe>
if you want debuggability, you want the compiler to probably not optimize a single thing
<phoe>
choose your poison
<beach>
whoman: The compiler is obviously only allowed to perform semantics-preserving transformations.
Ven`` has joined #lisp
<TMA>
whoman: semantic-preserving does not entail preserving the choices made under undefined behavior though
fikka has quit [Ping timeout: 265 seconds]
<beach>
TMA: Correct.
<phoe>
how can you preserve the semantics of that which has no semantics
<TMA>
exactly
scymtym has quit [Remote host closed the connection]
<rme>
And some compiler writers take great joy in rubbing your nose in undefined behavior.
<beach>
Indeed.
<beach>
I think GCC used to send email when #pragma was used.
<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.
<phoe>
beach: Yep, but then it's no longer "undefined" per se.
<beach>
Sure.
<phoe>
So defined = defined by the standard + additionally defined by the implementation.
<beach>
Right.
<emaczen>
pjb: is (reduce fn (mapcar (compose #'bt:join-thread (lambda (piece) (bt:make-thread ....))))) the correct form composition for map-reduce?
<pjb>
it's a way to do it, yes.
fikka has joined #lisp
<phoe>
I think so, yes.
<pjb>
Instead of compose, you can also use :key #'bt:join-thread ;-)
<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.
<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...
<phoe>
and it's harder to screw up with LPARALLEL than it is by rolling out your own implementations.
* phoe
- a good example
<emaczen>
can someone explain the complexities as to why my simple map-reduce is slow?
<phoe>
emaczen: show me your code
<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
loli has quit [Ping timeout: 268 seconds]
z3t0 has joined #lisp
marusich has quit [Ping timeout: 240 seconds]
<emaczen>
phoe: my code is not much more complicated than that (reduce fn (map ..)) form I showed earlier
<phoe>
emaczen: show it anyway
<emaczen>
where? is paste.lisp.org still down?
<phoe>
it's hard to get any concrete examples from speculation
<phoe>
pastebin.com
<phoe>
it is AFAIK
<whoman>
just pmap and lparallel and then time and then start getting the chisel out
DeadTrickster has quit [Read error: Connection reset by peer]
madrik has joined #lisp
DeadTrickster has joined #lisp
makomo has quit [Ping timeout: 240 seconds]
damke_ has quit [Ping timeout: 264 seconds]
saki has quit [Ping timeout: 256 seconds]
<smokeink>
some implementations have a Restart Frame Stepping option
<ludston>
emaczen: doing things in parallel is pretty easy. The tricky part is the synchronization afterwards.
damke_ has joined #lisp
nsrahmad has joined #lisp
makomo has joined #lisp
<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.
random-nick has joined #lisp
lnostdal has joined #lisp
saki has joined #lisp
kdridi has quit [Remote host closed the connection]
Murii has joined #lisp
<dim>
doing things concurrently is easy when it makes sense that every one is only minding their own business, computer beings involved or not ;-)
<dim>
(being... I guess... that typo has something to it tho)
sjl has joined #lisp
<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)
manualcrank has quit [Quit: WeeChat 2.0.1]
m00natic has joined #lisp
DeadTrickster has quit [Read error: Connection reset by peer]
lnostdal has quit [Remote host closed the connection]
DeadTrickster has joined #lisp
lnostdal has joined #lisp
Kevslinger has quit [Quit: Connection closed for inactivity]
kdridi has joined #lisp
sjl has quit [Ping timeout: 256 seconds]
<dim>
or do it the Erlang way: message passing only, share nothing
<Colleen>
beach: Got it. I'll let emaczen know as soon as possible.
orivej has joined #lisp
kdridi has quit [Ping timeout: 260 seconds]
damke_ has joined #lisp
damke has quit [Ping timeout: 264 seconds]
kdridi has joined #lisp
ak5 has quit [Ping timeout: 240 seconds]
SaganMan has quit [Quit: WeeChat 1.6]
nsrahmad has quit [Read error: Connection reset by peer]
nsrahmad has joined #lisp
shifty has joined #lisp
thallia has quit [Ping timeout: 268 seconds]
kdridi has quit [Remote host closed the connection]
thallia has joined #lisp
ak5 has joined #lisp
mishoo has quit [Ping timeout: 256 seconds]
nirved has joined #lisp
thallia has quit [Ping timeout: 260 seconds]
thallia has joined #lisp
<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 ) ?
nullman has quit [Ping timeout: 260 seconds]
nullman has joined #lisp
<smokeink>
.. and most lisps can't produce such small binaries .. ?
<beach>
smokeink: There is often a trade-off between speed and size due to inlining.
<dim>
compare with Go binary images maybe, or those produced by something that doesn't link/require libc at runtime
<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.
<dim>
IME most small executable binaries are small because they just rely on the right version of libc being there at runtime
<dim>
(but maybe I got that all wrong)
<phoe>
you bundle all of Lisp with your executables, that's why.
<beach>
smokeink: Having said that, I think someone should create a Common Lisp implementation where most of the code is in a shared library.
<phoe>
beach: you mean ECL?
<phoe>
(:
Ven`` has joined #lisp
<beach>
Maybe so.
mishoo has joined #lisp
<phoe>
the ECL binary is AFAIK just a tiny call to libecl.so
<beach>
smokeink: Then again, you might want to ask yourself whether it matters.
<phoe>
but I'm not a specialist here
<phoe>
jackdaniel: requesting support
<jackdaniel>
support for what?
<jackdaniel>
libecl may be reduced to around 200kb as well (just saying)
<phoe>
am I correct up there?
<phoe>
oh, I see
<jackdaniel>
ecl binary is indeed application linked with libecl which provides core runtime
<jackdaniel>
of course libecl may be statically linked in it (not by default though)
deba5e12 has quit [Quit: WeeChat 1.9.1]
deba5e12 has joined #lisp
<jackdaniel>
fwiw that's how ECL graphical application works on android – libecl is accessed via jni wrapper from java
<smokeink>
sbcl also depends on libc at runtime, doesn't it ?
<Shinmera>
What doesn't these days
kdridi has joined #lisp
<stacksmith>
sbcl.org is offline
<phoe>
stacksmith: Sourceforge is.
<jackdaniel>
sourceforge migration
<dmiles>
i wonder how muchg of ECL is available to external apps via libffi
<dmiles>
sounds like quite a bit
<phoe>
dmiles: AFAIK you can call Lisp from C in ECL, it provides the interface for it
mishoo has quit [Ping timeout: 240 seconds]
<jackdaniel>
dmiles: all functions are (unless they are bytecompiled, in that case you have to use cl_funcall)
<jackdaniel>
there is a calling convention for functions with &optional, &key etc as well as for closures
<jackdaniel>
that said, I'm focused on clim today :-)
<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)
kdridi has quit [Remote host closed the connection]
orivej_ has joined #lisp
kdridi has joined #lisp
fikka has quit [Ping timeout: 256 seconds]
<jackdaniel>
uh oh, figured out a bug I was tracing for an hour :)
orivej has quit [Read error: Connection reset by peer]
nsrahmad has quit [Read error: Connection reset by peer]
<jackdaniel>
fittestbits: I have good news for you, I've fixed the ticket you reported yesterday (will push in a minute)
<dmiles>
sometimes completely unrealated to all the troubleshooting :P
<jackdaniel>
not this time though :p
<dmiles>
optional
<dmiles>
oops
orivej_ has quit [Ping timeout: 248 seconds]
nsrahmad has joined #lisp
smurfrobot has joined #lisp
fikka has joined #lisp
makomo has quit [Ping timeout: 252 seconds]
kdridi has quit [Remote host closed the connection]
smurfrobot has quit [Ping timeout: 260 seconds]
fikka has quit [Ping timeout: 260 seconds]
python476 has quit [Ping timeout: 268 seconds]
kdridi has joined #lisp
vap1 has quit [Remote host closed the connection]
kdridi has quit [Remote host closed the connection]
kdridi has joined #lisp
thallia has quit [Ping timeout: 264 seconds]
fikka has joined #lisp
kdridi has quit [Remote host closed the connection]
thallia has joined #lisp
thallia has quit [Ping timeout: 265 seconds]
attila_lendvai has quit [Read error: Connection reset by peer]
thallia has joined #lisp
attila_lendvai has joined #lisp
nsrahmad has quit [Quit: Leaving]
smaster has joined #lisp
iridioid has quit [Ping timeout: 256 seconds]
madrik has quit [Remote host closed the connection]
<scymtym>
fe[nl]ix: could you make a fiveam release? i think the accumulated changes justify one
sjl has joined #lisp
sjl__ has joined #lisp
<fe[nl]ix>
will do
sjl has quit [Ping timeout: 240 seconds]
<scymtym>
thank you
<fe[nl]ix>
scymtym: please test it in the meanwhile
<scymtym>
fe[nl]ix: anything in particular? i'm using master all the time without problems
Ven`` has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
gabiruh has joined #lisp
<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
raynold has quit [Quit: Connection closed for inactivity]
<Xach>
I don't think anyone here is in the intended audience
<fourier>
heh they will always say its alive :)
sjl__ has quit [Ping timeout: 264 seconds]
<Xach>
fourier: I don't think that's certain.
fikka has quit [Ping timeout: 248 seconds]
Cymew has quit [Ping timeout: 248 seconds]
fdund has joined #lisp
makomo has joined #lisp
<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.
<phoe>
Update on SBCL: SFnet still works on their transition, they are not done yet.
saki has quit [Ping timeout: 276 seconds]
<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.
<raynold>
Ahh it's a wonderful day
<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.
saki has joined #lisp
<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).
<pjb>
(and kotlin and swift can run on the server as well).
<fourier>
pjb: thats what I suspected.
Ven`` has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<pjb>
fourier: you can have a look at the #-mocl in com.informatimago to evaluate if that would be a problem for you.
<fourier>
I was generally curious, since it was promising on startup, but faded away
Cymew has joined #lisp
<pjb>
Again, while I'm dissatisfied, it can meet your requirements, so I wouldn't discard it without an evaluation.
<pjb>
Perhaps in practice it can still be useful.
<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…
<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.
<fourier>
architecture wise most of the time it is better, easy to maintain etc.
Cymew has quit [Ping timeout: 276 seconds]
Cymew has joined #lisp
<pjb>
Sure, if you have this core computation. But this is not the case in 75% of mobile applications.
Ven`` has joined #lisp
fikka has joined #lisp
Cymew has quit [Ping timeout: 240 seconds]
fikka has quit [Ping timeout: 240 seconds]
fourier has quit [Ping timeout: 256 seconds]
lucasb has quit [Quit: leaving]
sjl__ has joined #lisp
sjl has joined #lisp
fikka has joined #lisp
fourier has joined #lisp
sjl__ has quit [Ping timeout: 248 seconds]
fikka has quit [Ping timeout: 256 seconds]
test1600 has quit [Ping timeout: 276 seconds]
fikka has joined #lisp
fikka has quit [Ping timeout: 240 seconds]
pfdietz_ has quit [Ping timeout: 240 seconds]
lksmk has quit [Quit: leaving]
fdund has quit [Ping timeout: 264 seconds]
fikka has joined #lisp
kotrcka has joined #lisp
fikka has quit [Ping timeout: 256 seconds]
fdund has joined #lisp
dieggsy has joined #lisp
rstandy has quit [Quit: ERC (IRC client for Emacs 24.5.1)]
fikka has joined #lisp
nowhere_man has quit [Ping timeout: 248 seconds]
Tobbi has quit [Remote host closed the connection]
fikka has quit [Ping timeout: 248 seconds]
Tobbi has joined #lisp
emaczen has joined #lisp
EvW1 has joined #lisp
<emaczen>
will anyone explain some details about the complexities of writing your own concurrency especially via (reduce (map ...))?
LocaMocha has quit [Remote host closed the connection]
attila_lendvai has quit [Read error: Connection reset by peer]
attila_lendvai has joined #lisp
attila_lendvai has joined #lisp
attila_lendvai has quit [Changing host]
Arcaelyx has quit [Ping timeout: 248 seconds]
<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?
<emaczen>
Is partitioning your data into the amount of cores your machine has a good idea?
Arcaelyx has joined #lisp
epony has joined #lisp
orivej has joined #lisp
<Bike>
does "highly parallelizable" mean it's not actually parallelized?
<emaczen>
Bike: Let me see if I can find my paste from last night
smaster has joined #lisp
milanj has quit [Ping timeout: 248 seconds]
smaster has quit [Ping timeout: 252 seconds]
milanj has joined #lisp
borei has joined #lisp
Arcaelyx has quit [Max SendQ exceeded]
<borei>
hi all !
<jmercouris>
hello
EvW1 has quit [Ping timeout: 260 seconds]
<borei>
can somebody point me to the right direction
Ven`` has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
nullman has quit [Ping timeout: 256 seconds]
Arcaelyx has joined #lisp
nullman has joined #lisp
<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?
<Bike>
you also don't tell it the rank of the array
<borei>
element type is (simple-array single-float (4))
<Bike>
borei: then you can write (the (simple-array (simple-array single-float (4)) (*)) (elements matrix))
attila_lendvai has quit [Read error: Connection reset by peer]
<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.
<Bike>
and how big is n, here?
<emaczen>
I'm testing with 10^4 and then I will keep increasing by a power.
dmiles has quit [Read error: Connection reset by peer]
vultyre has quit [Read error: Connection reset by peer]
attila_lendvai has joined #lisp
attila_lendvai has joined #lisp
attila_lendvai has quit [Changing host]
Ven`` has joined #lisp
<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.
<Bike>
and you do that entirely serially.
dmiles has joined #lisp
<emaczen>
Bike: correct
milanj_ has joined #lisp
dmiles has quit [Excess Flood]
<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.
fikka has joined #lisp
<emaczen>
Bike: Okay, let me try again then
<Bike>
Can you not just use lparallel?
<Bike>
The task is kind of fundamentally flawed, I think. Consing the list is probably going to be more expensive than arithmetic.
dmiles has joined #lisp
<emaczen>
Bike: This is an over simplistic test scenario. In general I have a lot of programs that could be map-reduced
milanj has quit [Ping timeout: 260 seconds]
<Bike>
i'm sure, but i'm just telling you that amdahl's law is telling you this isn't going to work.
damke has quit [Ping timeout: 264 seconds]
<Bike>
Do you know how append works? It makes new lists. You're doing way more consing in the parallel version.
<Bike>
lparallel has implementations of map reduce. i haven't used it myself but it looks pretty robust.
dmiles has quit [Excess Flood]
vultyre has joined #lisp
Achylles has joined #lisp
<_death>
maybe instead of just timing it, profile it so you can see where time is spent.. and do this with the "real" code
damke has joined #lisp
nowhere_man has joined #lisp
<Bike>
indeed
fikka has quit [Ping timeout: 265 seconds]
dmiles has joined #lisp
Fare has joined #lisp
pfdietz has quit [Ping timeout: 240 seconds]
dmiles has quit [Excess Flood]
Karl_Dscc has joined #lisp
<emaczen>
Bike: thanks, those words helped.
<emaczen>
I see what you mean
manualcrank has joined #lisp
dmiles has joined #lisp
dmiles has quit [Excess Flood]
<emaczen>
Bike: I create the partitions in each thread now, and did not reduce and it is faster
<emaczen>
With my custom linked-list I can probably get away with a lot of this
igemnace has joined #lisp
Ven`` has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
fikka has joined #lisp
dmiles has joined #lisp
Pixel_Outlaw has joined #lisp
vultyre has quit [Quit: Leaving]
sjl__ has joined #lisp
fikka has quit [Ping timeout: 268 seconds]
sjl has quit [Ping timeout: 240 seconds]
fourier has quit [Ping timeout: 248 seconds]
fikka has joined #lisp
random-nick has joined #lisp
fikka has quit [Ping timeout: 276 seconds]
<borei>
Bike: your code works
<borei>
but on the other hand, i tried the following
<borei>
(lane (aref (the simple-vector (elements matrix)) lane-index))
<borei>
no notes, now im trying to understand are both forms equevalent ?
heurist`_ has joined #lisp
<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)))
<Bike>
(it's T)
<Bike>
simple-vector is shorthand for (simple-array T (*))
<Bike>
since your specified element type of (simple-array single-float (4)) upgrades to T, the two types are equivalent.
pyface has joined #lisp
heurist` has quit [Ping timeout: 256 seconds]
<borei>
ic
scymtym has quit [Ping timeout: 255 seconds]
sjl__ is now known as sjl
Cymew has joined #lisp
<borei>
does anybody has experience with simd-pack data type ?
<borei>
i found how to pack data, but how to unpack ???
vlatkoB has quit [Remote host closed the connection]
python476 has joined #lisp
Cymew has quit [Ping timeout: 240 seconds]
<Bike>
does #s syntax for structures not work if :type is specified? I thought it did, but it doesn't on SBCL.
Rawriful has joined #lisp
Denommus has quit [Ping timeout: 276 seconds]
attila_lendvai has quit [Quit: Leaving.]
Achylles_ has joined #lisp
Achylles_ has quit [Max SendQ exceeded]
mjl_ has quit [Ping timeout: 260 seconds]
<_death>
it type is list or vector, I don't think it's supposed to work.. /me checks clhs
Karl_Dscc has quit [Remote host closed the connection]
smaster has joined #lisp
jmercouris has quit [Ping timeout: 240 seconds]
<Bike>
i suppose "structure type" means there's an actual type, meaning it's not :type
<Bike>
kind of unclear to me, tho
papachan has quit [Quit: WeeChat 2.0.1]
<_death>
that's my reading of it
<razzy>
beach: yeah, i was thinking of primitive implementations :].
smaster has quit [Quit: WeeChat 2.0.1]
smasta has joined #lisp
scymtym has joined #lisp
jmercouris has joined #lisp
<jmercouris>
suggestions on tutorials or libraries to work with sockets in CL?
andrew` has joined #lisp
<Shinmera>
usocket
<Shinmera>
Otherwise it's no different than socket stuff in any other language
<jmercouris>
Shinmera: ok, great, thank you!
andrew` has left #lisp ["ERC (IRC client for Emacs 25.2.1)"]
comborico1611 has joined #lisp
pfdietz has joined #lisp
neirac has quit [Ping timeout: 248 seconds]
<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 ?
neirac has joined #lisp
<pfdietz>
Yes, only actual structures. Look up def of structure in the glossary.
<pfdietz>
Not sure you can say structure-object there.
<dmiles>
yeah i sorta want something sayable
<dmiles>
this is for my own impl.. but i'd like to align with at least some other impl somewhere
pagnol has joined #lisp
smasta has quit [Ping timeout: 256 seconds]
mnoonan has quit [Quit: Leaving]
<dmiles>
"defined by the implementation to be appropriate." so wondering has anyone ever came up with "appropriate."
openthesky has joined #lisp
<dmiles>
why i care is that i am adding some things like HASH-TABLE JSON-MAP etc
<phoe>
it seems that the spec says that this behaviour is implementation-defined
<phoe>
so feel free to define it, you're the implementer (:
<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
nowhere_man has quit [Ping timeout: 240 seconds]
<Bike>
you can't say structure-object there
nowhere_man has joined #lisp
<phoe>
Bike: why?
<Bike>
nevermind.
<phoe>
I am actually confused about that part
smasta has joined #lisp
<phoe>
mostly because, IMO, DEFSTRUCT is the worst page of the spec
<phoe>
so I'll welcome any clarifications on the matter
makomo has quit [Ping timeout: 240 seconds]
<phoe>
...actually I think I see why
<Bike>
well, in a few places it specifies that so-and-so works if :type is specified or not specified.
<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."
<Bike>
So you'd be rewriting that to mean "if :type is unspecified or structure-object"
<Bike>
also it's kind of pointless.
<whoman>
o_o
<phoe>
so if you specify :TYPE option at all, then some parts of DEFSTRUCT just don't work anymore.
<phoe>
like, if you specify TYPE, then the structure no longer defines a type of its own.
<Bike>
yeah.
<phoe>
so if you specify STRUCTURE-OBJECT there, then you get an object without a defined type of its own.
<phoe>
Sure, it's a structure-object now, but it doesn't have a type of its own.
<Bike>
defstruct kind of does two different things that are similar enough that they mashed them together.
fikka has joined #lisp
hhdave has joined #lisp
<whoman>
=(
<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.
<phoe>
which are list and vector in the standard, but an implementation is permitted to use other DSes as well.
<Bike>
it's not a place i'd choose to "innovate"
<phoe>
yep, me too
rumbler3_ has joined #lisp
openthesky has quit [Quit: Leaving.]
rumbler3_ has quit [Remote host closed the connection]
neirac has quit [Ping timeout: 256 seconds]
hhdave has quit [Quit: hhdave]
neirac has joined #lisp
iridioid has joined #lisp
smasta has quit [Ping timeout: 268 seconds]
damke has quit [Ping timeout: 264 seconds]
LiamH has quit [Quit: Leaving.]
<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?
Fare has quit [Ping timeout: 240 seconds]
Murii has quit [Quit: WeeChat 1.4]
pfdietz has quit [Ping timeout: 260 seconds]
<jmercouris>
I did find IOLib which definitely supports Unix sockets, but (ql:who-depends-on "iolib/sockets") returns nil
<jmercouris>
not sure if my query is malformed, or if there is really nobody using it
pfdietz has joined #lisp
nullman has quit [Ping timeout: 256 seconds]
damke has joined #lisp
nullman has joined #lisp
<jmercouris>
what are "bsd style sockets"?
<phoe>
unix sockets
fikka has quit [Ping timeout: 240 seconds]
<phoe>
bsd is unix
<jmercouris>
is there a difference between a unix domain socket and a "bsd style socket"?
<phoe>
I guess not?
<phoe>
both of them are completely local AFAIK
Fare has joined #lisp
<jmercouris>
someone on stack overflow said usocket supports "BSD style sockets"
<jmercouris>
trying to figure out what that could possibly mean
pfdietz has quit [Ping timeout: 276 seconds]
<TMA>
bsd style sockets are other name for (a) tcp sockets (b) the whole socket(2) syscall ecosystem
<jmercouris>
rme: so you're thinking about putting in support for what precisely? unix domain sockets as an extension to CCL?
<Josh_2>
Why not just use Usocket like
<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.
thallia has joined #lisp
<jmercouris>
Josh_2: I do not want to deal with http/loopback interfaces, ports etc etc
<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
<Josh_2>
How do you not use ports with networking?'
<jmercouris>
Josh_2: I am not doing networking, I am doing IPC
<jmercouris>
Josh_2: there is only one computer involved, and two processes are communicating via a special type of file
<Josh_2>
What like slime?
<jmercouris>
Josh_2: I'm not sure what slime uses
<Josh_2>
Uses sockets in the background doesn't it?
<jmercouris>
no, I belive slime is using I guess they are called bsd sockets
<jmercouris>
because slime specifies an IP and port
<jmercouris>
Josh_2: for what exactly? which C library?
<Josh_2>
Surely the Linux kernel has IPC no?
<jmercouris>
Josh_2: lots of C libraries run on linux, bsd, and osx
<jmercouris>
Josh_2: the Linux kernel, I don't know enough about it to say how it performs IPC
<jmercouris>
or rather facilitates
<Josh_2>
IPC requires socket like communication inside the kernel
<jmercouris>
I guess I could make CFFI bindings to some C domain socket library
White_Flame has quit [Quit: No Ping reply in 180 seconds.]
<jmercouris>
Josh_2: I'm not sure I'm following you
<jmercouris>
Josh_2: why does IPC require socket like communication inside the kernel?
<Josh_2>
That's what it said no? " all communication occurs entirely within the operating system kernel."
White_Flame has joined #lisp
iridioid has quit [Ping timeout: 276 seconds]
<Shinmera>
jmercouris: When you say "sockets" the natural conclusion I come to is UDP/TCP sockets. Unix domain sockets are more special requirements.
<whoman>
shared memory, shm
<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
<Shinmera>
jmercouris: Just explaining why I suggested what I did.
<whoman>
i would do shared memory filesystem , myself
python476 has quit [Ping timeout: 240 seconds]
<jmercouris>
Josh_2: In a sense perhaps, as both processes are reading and writing to a file via sys calls
<Josh_2>
I just quoted what was in the Wiki article
<jmercouris>
Josh_2: unless you mean something else, in which case I don't understand
<Josh_2>
first line second paragraph
<jmercouris>
Right, I see that now
<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
<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
<jmercouris>
or maybe there is some special kernel facilities for domain sockets that I don't know about
<whoman>
ummm just do http if you are doing multiple platforms ...
<jmercouris>
Josh_2: there may be one library written in C with three implementation Linux, OSX, and Windows
<jmercouris>
whoman: I'm only focusing OSX and Linux right now
<whoman>
NSDistributedNotificationCenter on gnustep-base for all 3 operating systems.
<whoman>
ah, that greatly simplifies =) plans for windows in future though?
<Josh_2>
Seems like a large amount of work when you could just put (let ((hostname "127.0.0.1)(port 45456))) :P
d0peCanoe has quit [Ping timeout: 264 seconds]
<jmercouris>
whoman: that is very interesting
<Josh_2>
use normal sockets
<jmercouris>
If the pain is too great, I'll use normal sockets
<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.
<whoman>
a lot of stuff is doing http/rest now , maybe thats why? ^_^
<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
<whoman>
got to know when going down the back roads
<jmercouris>
whoman: because one is strictly foreign code, and one is strictly lisp
<whoman>
suddenly the ride is rough, turns to gravel =)
<jmercouris>
whoman: It's definitely not an easy project, possibly a huge waste of time, but I think it's a good experience regardless
<whoman>
hmmm. i ran into that situation recently, (in concept), and decided to use ECL for the lisp and all is well
<jmercouris>
basically the lisp will be the core, and the other program, whether objective-c, c++, or c will be a "dumb" front end
Josh_2 has quit [Remote host closed the connection]
<whoman>
oh except, my situation was exactly inverse =)
<whoman>
lisp usermode/userintfc surrounding the foreign 'gutsbrain' code
<jmercouris>
yeah, ECL is an interesting idea, but that will only work for C implementations
<jmercouris>
there isn't really a C API for cocoa, for example
<whoman>
not c++ ? would have to make a C api in between if objc/c++ is involved.. hmm
<jmercouris>
I mean, it's most technically possible, but it adds lots of difficulties for nor eason
<whoman>
yeah =) hmm. Electron =)
<jmercouris>
Please, no
<jmercouris>
electron is my arch nemisis lol
<whoman>
there there
<whoman>
dont u web browse errday
<jmercouris>
Yeah, but I don't need my text editor to be a web browser
<whoman>
see now we are getting into some metaphysical existential parapsychology stuff ehh !
d0peCanoe has joined #lisp
<whoman>
heh sorry i only assumed that your mention of cocoa means you will wrap lisp with UI
<jmercouris>
whoman: that's exactly what I will do
<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 ^_^
<whoman>
there was the deduction for solution, now its up to you to forge your own path my friend ~
<jmercouris>
Lol, it's not that simple
<jmercouris>
damnit iolib does not want to work on OSX
<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