kajo has quit [Quit: From my rotting body, flowers shall grow and I am in them and that is eternity. -- E. M.]
jmercouris has quit [Remote host closed the connection]
<rdh>
hello, I have a question regarding using sbcl for hard/firm real-time... I am building a flight controller using linux for a drone, but the more i think about this task the more i realize the importance of the sensors and motor controls being top priority on the linux system.
<oni-on-ion>
kevent
<oni-on-ion>
and/or libev
<Xach>
oni-on-ion: you didn't wait for the question!
<rdh>
haha
<galdor>
I'm not sure SBCL and Linux are the right solution for a hard real-time system
<phoe>
linux might be, since there hard real time patches for it - but SBCL might not be since it has little guarantees about e.g. its GC performance
<grewal>
For realtime, you'd just need to control the gc more
<phoe>
or that
<oni-on-ion>
im rolling dice =) ECL can be possibly closer to system than SBCL ?
<rdh>
ok, my idea was to set the niceness of the lisp program to high, and use c libs for interfacing with the sensors... but where could i find more info on controlling the gc?
<phoe>
rdh: in your implementation's manual - the standard doesn't specify anything like that
<no-defun-allowed>
Could I write (let ((x 0)) (values (lambda () (incf x)) (lambda () x))) and call the first closure to increment the value produced by calling the second?
vidak` has quit [Remote host closed the connection]
<copec>
I believe so, but don't quote me on that.
<copec>
I'm still just poking at Rust in my spare time
<copec>
mostly because I hear about how great its memory control is for systems code
<no-defun-allowed>
Much ado about nothing.
<copec>
yesh
* ArthurStrong
heard Rust is just like C++ with unique_ptr everywhere
libertyprime has joined #lisp
vidak` has joined #lisp
hhdave has quit [Ping timeout: 258 seconds]
longshi has quit [Ping timeout: 260 seconds]
lavaflow has quit [Read error: Connection reset by peer]
lavaflow has joined #lisp
<copec>
no-defun-allowed, yeah you can modify via a closure, but it is only ever a single reference that is borrowed in Rust vernacular.
<no-defun-allowed>
"A big fuss over a trifle, as in Jerry had everyone running around looking for his gloves—much ado about nothing. Although this expression is best remembered as the title of Shakespeare's comedy, the phrase much ado was already being used for a big commotion or trouble in the early 1500s."
xkapastel has joined #lisp
X-Scale has joined #lisp
<copec>
I'm sure, but it's not of colloquial use around these parts except for in reference to Shakespeare, and I rather enjoy Josh Whedon's version.
khisanth_ has quit [Ping timeout: 265 seconds]
Lord_of_Life has quit [Ping timeout: 258 seconds]
Lord_of_Life has joined #lisp
khisanth_ has joined #lisp
libertyprime has quit [Quit: leaving]
mangul has joined #lisp
MinnowTaur has quit [Ping timeout: 260 seconds]
zaquest has quit [Quit: Leaving]
zaquest has joined #lisp
wxie has quit [Ping timeout: 268 seconds]
quazimodo has quit [Read error: Connection reset by peer]
refpga has quit [Ping timeout: 258 seconds]
quazimodo has joined #lisp
Oladon has joined #lisp
scatterp has joined #lisp
<beach>
Good morning everyone!
karlosz has quit [Quit: karlosz]
MinnowTaur has joined #lisp
hhdave has joined #lisp
vidak` has quit [Read error: Connection reset by peer]
karlosz has joined #lisp
<koenig>
jackdaniel and eeeeeta: Success! After *much* debugging, I observed that WeeChat has a plugin that loads the Guile interpreter.
<koenig>
Guile uses a lot of the same special libraries that ECL uses, such as Bignum and stuff.
<oni-on-ion>
T_T i wanted to suggest that this morning. but i refrained because #lisp only is CL =(
<koenig>
HAHAHAHAHA
<koenig>
I don't trust Schemers... :) :) :)
<no-defun-allowed>
#f off
<oni-on-ion>
because they scheme? ^_^
<koenig>
Man, I am so relieved I've figured this out finally. I can do some very basic calls between WeeChat handlers and ECL now.
<koenig>
A good side-effect is that I know a lot more about the internals of ECL (and WeeChat) now. I've single stepped through the ECL initialization so many times now.
<koenig>
I predict this project is going to get a lot more fun pretty quickly now.
epony has quit [Quit: upgrades]
_whitelogger has joined #lisp
_whitelogger has joined #lisp
epony has joined #lisp
mangul has quit [Ping timeout: 258 seconds]
slyrus has joined #lisp
mangul has joined #lisp
whiteline has quit [Ping timeout: 258 seconds]
mangul has quit [Ping timeout: 260 seconds]
FreeBirdLjj has joined #lisp
ArthurSt1ong has joined #lisp
ArthurStrong has quit [Ping timeout: 258 seconds]
ggole has joined #lisp
bilegeek has joined #lisp
Bike has quit [Quit: Lost terminal]
bilegeek has quit [Quit: Leaving]
ArthurSt1ong has quit [Quit: leaving]
dddddd has quit [Ping timeout: 260 seconds]
Oladon has quit [Quit: Leaving.]
narimiran has joined #lisp
rippa has joined #lisp
vlatkoB has joined #lisp
orivej has joined #lisp
hhdave has joined #lisp
ozzloy has quit [Remote host closed the connection]
untakenstupidnic has joined #lisp
untakenstupidnic has quit [Remote host closed the connection]
easye`` has quit [Ping timeout: 265 seconds]
orivej has quit [Ping timeout: 258 seconds]
Oladon has joined #lisp
hhdave has quit [Ping timeout: 258 seconds]
karlosz has quit [Quit: karlosz]
karlosz has joined #lisp
akrl has quit [Ping timeout: 258 seconds]
wxie has joined #lisp
TheAlemazing has joined #lisp
TheAlemazing has quit [Read error: Connection reset by peer]
TheAlemazing has joined #lisp
Qudit314159 has joined #lisp
* TheAlemazing
whois
jonatack has joined #lisp
xkapastel has quit [Quit: Connection closed for inactivity]
wxie has quit [Ping timeout: 258 seconds]
libertyprime has joined #lisp
gravicappa has joined #lisp
karlosz has quit [Quit: karlosz]
FreeBirdLjj has quit [Remote host closed the connection]
<beach>
TheAlemazing: What are you looking for?
FreeBirdLjj has joined #lisp
retropikzel has joined #lisp
FreeBirdLjj has quit [Ping timeout: 260 seconds]
akrl has joined #lisp
Oladon has quit [Quit: Leaving.]
whiteline has joined #lisp
quazimodo has quit [Ping timeout: 240 seconds]
ebrasca has joined #lisp
quazimodo has joined #lisp
torbo has quit [Remote host closed the connection]
ebzzry has quit [Ping timeout: 258 seconds]
<eeeeeta>
koenig: wait, so did you give up on ECL, or did you get it working?
<jackdaniel>
I think that he got it working. Given guile was started at the same time, I suspect that i.e libgc was initialized twice
<jackdaniel>
(once by guile init and the second time by ecl)
atgreen has joined #lisp
orivej has joined #lisp
<jackdaniel>
as of not trusting schemers, I would object, but looking at the ticket: https://savannah.nongnu.org/task/?7289 "task: Common Lisp support", and the resolving message "Done, with guile. New plugin: \"Guile\"" I'd say that this scheme dev is pretty cunning ,-)
Buggys has joined #lisp
<Shinmera>
Hmmm! Having ECL with Weechat would lessen the effort needed to get a Lichat plugin going a lot
__vlgvrs has joined #lisp
_paul0 has quit [Ping timeout: 252 seconds]
<eeeeeta>
a lichat plugin?
<eeeeeta>
jackdaniel: ah, makes sense
Qudit314159 has quit [Remote host closed the connection]
<jackdaniel>
of course if I were to make a wishlist contest, I'd say that libgc should signal a condition (OK, printf a message - it is C after all!) and carry on without crashing ;) but libgc is excellent aid in unix world nevertheless
mangul has quit [Remote host closed the connection]
mangul has joined #lisp
hhdave has quit [Ping timeout: 258 seconds]
mangul has quit [Remote host closed the connection]
mangul has joined #lisp
Lord_of_Life has quit [Ping timeout: 258 seconds]
Lord_of_Life has joined #lisp
papachan has quit [Quit: Leaving]
random-nick has quit [Ping timeout: 268 seconds]
<duuqnd>
I've gotten OpenGenera working on Linux except that using the meta (alt) key doesn't work (it works in xterm but not in the VLM window). Does anyone know what the problem might be?
clothespin has joined #lisp
random-nick has joined #lisp
epony has quit [Quit: reconf]
<p_l>
check what key is reported when you hit alt
epony has joined #lisp
<p_l>
I think there used to be some bits of mapping that had to be changed?
nowhere_man has quit [Ping timeout: 265 seconds]
<duuqnd>
I'm not sure. I've noticed that when I hold Meta/Alt and press buttons on the top-row it types some strange characters.
<duuqnd>
Not just top-row actually.
<duuqnd>
A lot of keys do it.
<duuqnd>
p_l: I'm not really that experienced with Genera so I'm not sure how I'd see what keys are pressed.
<p_l>
duuqnd: under X11, a program (run in terminal) called `xev`
<duuqnd>
xev's telling me that I'm pressing the left alt key.
<duuqnd>
Alt works fine in xterm too, just not in the VLM.
FreeBirdLjj has joined #lisp
sjl has quit [Quit: WeeChat 2.2-dev]
<duuqnd>
I'm thinking that maybe it interprets Left Alt as the symbol key.
<duuqnd>
That wouldn't really make sense though, since symbol is supposed to be bound to Numpad 8.
cosimone has quit [Quit: Terminated!]
<duuqnd>
Right Alt does the same thing, so I'm quite confused.
<p_l>
It should give you Meta_L, afaik
<duuqnd>
Yeah, that's what I've been seeing too.
<p_l>
I'm not at the computer right now, but there is a xmodmap file floating around to handle that
<duuqnd>
I'll look for that, thanks. I'll also read through the snap4 README and see if there's anything there.
<duuqnd>
The snap4 README mentions that Right Control is bound to Super, though, and that doesn't seem to be true. It also says that resizing the window doesn't work, but I've had no problems with it.
<p_l>
The issue is right in the name - the "snap" refers to "snapshot" and it was a bit broken both in snap4 and snap5
<duuqnd>
I haven't been able to find anything newer than snap4.
<duuqnd>
Where could I find the latest version?
<p_l>
Then you have the issue that OpenGenera, despite 2.0 number, is more of a beta..
<p_l>
duuqnd: snap5 never worked for me
<p_l>
Nor did the community patched versions
<duuqnd>
Yeah, I'm using snap4 because it's the one thing that worked. All the others either didn't work at all or wouldn't let me reload a saved world.
whiteline has quit [Remote host closed the connection]
whiteline has joined #lisp
<bitmapper>
yeah, snap5 didn't work
<bitmapper>
i still haven't gotten snap6 to work either
<duuqnd>
I wonder where the xinput code would be. Would it be in the VLM or in Genera itself?
<duuqnd>
In the VLM I can only find mentions of input in relation to the cold load window.
karlosz has joined #lisp
karlosz has quit [Remote host closed the connection]
<bitmapper>
a bit of both
<duuqnd>
I'm gussing the actual X key to Genera key translation is done in Genera. Good thing Genera comes with the source code.
<bitmapper>
well, most of it
<duuqnd>
There's enough of it for it to be useful. It would be nice to have it all, but most is better than none.
clothespin has quit []
EvW has quit [Ping timeout: 245 seconds]
clothespin has joined #lisp
<p_l>
duuqnd: most of X11 handling is done in Genera
<duuqnd>
I found a package called xlib, so I'll try looking through that.
nowhere_man has joined #lisp
zaquest has quit [Quit: Leaving]
<duuqnd>
I found something in sys.sct/x11/clx/translate.lisp. I think it's defining keysyms. I'll try changing that.
<p_l>
duuqnd: it helps to have old X11 unless you have modelock patch applied
<duuqnd>
Yeah, I'm running Ubuntu 7.10 in a VM.
<p_l>
I keep an ubuntu image from I think 8.04 for that yeah
<duuqnd>
Right now I'm just trying to figure out why it maps my alt keys to Symbol.
<nirved>
duuqnd: what kind of VM?
<duuqnd>
nirved: I'm using VirtualBox, but I've had success with VMWare too.
zaquest has joined #lisp
<nirved>
duuqnd: there was something about alt keys and running fullscreen without mouse integration
<duuqnd>
My alt keys actually work, they're just bound to the Symbol key for some reason.
<duuqnd>
The reason seems to be that in Genera's xlib, left meta has the keysym #xFFE7, but the actual keysym for left alt is #xFFE9.
<nirved>
does KP8 work as SYMBOL as well?
<duuqnd>
I'll try.
<duuqnd>
No, it doesn't.
<duuqnd>
There seems to be some strange definitions in xlib... left-meta-keysym exists, but so does left-alt-keysym. Now, that sounds like meta is actually supposed to be super, but left-super-keysym is also there.
jmercouris has joined #lisp
<duuqnd>
I think I've got it... Maybe. So, I might be wrong here, but it seems that Alt, Meta, Super and Hyper are all different keys according to X. Genera maps X11 Meta to its own Meta keys, but my keyboard spits out Alt keysyms.
<nirved>
does xev in host return the same keysym as xev in guest?
<duuqnd>
I don't have xev installed on my host, but I can probably fix this by telling Genera to use X11 Alt key instead of X11 meta.
<duuqnd>
Then I can remap Symbol to something else.
<duuqnd>
I switched meta and alt in keysyms.lisp, so now all I need to do is to reload the keysyms.lisp file and make a new world file. Hopefully that will work.
<p_l>
duuqnd: there's also keyboard definition system you can use later
<duuqnd>
What's that?
Mandus has quit [Quit: WeeChat 2.4]
<p_l>
A system to define mappings for Genera to adapt to different keyboards
<phoe>
'(:a 1 :b 2) is a plist with one key that is the symbol QUOTE and one value that is the list (:a 1 :b 2)
<galdor>
oh of course
<galdor>
this is really stupid
<galdor>
thank you
<phoe>
which is a perversion of how plists are supposed to work, but nonetheless, it's getting interpreted like that since MACROLET macros get its arguments unevaluated
<phoe>
s/its/their/
<phoe>
see a similar version, (macrolet ((foo (plist) `(list ,(getf plist 'quote)))) (foo '(:a 1 :b 2)))
shifty has joined #lisp
<galdor>
this kind of thing isn't easy to debug
<galdor>
but now I get the idea
xkapastel has quit [Quit: Connection closed for inactivity]
<MichaelRaskin>
Well, you can ask your macro to print stuff during the expansion
<phoe>
nowadays I debug macros via macrostep mode - it's amazing
__vlgvrs is now known as paul0
<phoe>
inline macroexpansions are amazing
<galdor>
I did not know about macrostep
<galdor>
now I have to read about it, this is exactly what I wanted
<phoe>
you want M-x macrostep-expand
<phoe>
once macrostep mode is triggered, use [e] to expand, [c] to collapse, [q] to quit
<phoe>
use your emacs point to tell emacs which macro form should be expanded next.
<p_l>
phoe: on Windows you would have the option of doing a DCOM server
<phoe>
p_l: can't do that, I need it to work on Linux.
<jeosol>
Morning guys
random-nick has joined #lisp
<jeosol>
Just want to confirm that it's still not possible to create core file from within EMACS+SLIME and only through shell. I am running sbcl and get the usual "Cannot save core with multiple threads running". I am not sure if this has changed yet. Thanks
<jeosol>
Or there is some kind of work around I am not aware of.
oni-on-ion has joined #lisp
<phoe>
jeosol: this won't change AFAIK - if anything, you could script emacs to automatically run the inferior lisp and issue (asdf:make :myproject)
<phoe>
like, slime has nothing to do with it
<phoe>
swank has its own threads running, so running swank at all prevents core dumping.
<MichaelRaskin>
phoe: does your library need large amounts of data in the arguments or in the results?
<oni-on-ion>
phoe, not sure what is the situation, but would running lisp outside of emacs help ? then connect w/ slime
<jeosol>
phoe: Thanks for that.
v88m has joined #lisp
<phoe>
oni-on-ion: nope, you cannot use slime on an image that you use for dumping a heap. Unless you somehow cause swank to take over the single thread of that image.
<jeosol>
I have an application that takes time to load so I prefer to use core file for fast restart. Often, I go off emacs+slime, load SBCL on shell, just to dump the core file and come back to emacs+slime, so I reload that updated image and continue developing.
<phoe>
MichaelRaskin: not really, less than a kilobyte per call.
<oni-on-ion>
ohhh, right right
random-nick has quit [Ping timeout: 268 seconds]
<phoe>
jeosol: that's impossible with multithreaded swank loaded.
<jeosol>
I don't do it every time but sometimes after making some incompatible change, and need to recreate the core file. This is also application specific
<jeosol>
phoe: I am in agreement. I knew it was the case, but thought may be there was work around by this time.
<jeosol>
Thanks
<MichaelRaskin>
phoe: does latency (context-switch overhead) matter for the library?
Achylles has quit [Quit: Leaving]
bitmapper has quit [Remote host closed the connection]
bitmapper has joined #lisp
frgo_ has joined #lisp
<phoe>
MichaelRaskin: I think I've found the way, and it's called ECL. It exposes what I want.
<phoe>
Or rather, it allows a Lisp function to be called from C.
<MichaelRaskin>
That's true; be careful about the signal use, though
<MichaelRaskin>
Just yesterday in this channel there was a conversation about debugging ECL use inside a WeeChat plugin…
frgo has quit [Ping timeout: 240 seconds]
bitmapper has quit [Ping timeout: 268 seconds]
<jackdaniel>
the problem was apparently double inititialization of some shared libraries (like libgc) by both guile and ecl
xvx has joined #lisp
<MichaelRaskin>
The second problem, after the signal conflict was sorted out?
gravicappa has quit [Ping timeout: 260 seconds]
<p_l>
jackdaniel: sounds like a reason to support more separation in compilation
<jackdaniel>
maybe, it was unclear to me from the conclusion
<jackdaniel>
p_l: ?
<jackdaniel>
it is already possible to statically link libgc with ecl, and it doesn't interfere with shared libgc
<jackdaniel>
(same goes for gmp and libffi)
<p_l>
jackdaniel: nice
<p_l>
Now I only need to finally test static compile against musl
bitmapper has joined #lisp
<jackdaniel>
as of making libgc more resilent to double initialization it is a question to bdwgc maintainers
random-nick has joined #lisp
Vodyanoy has quit [Quit: Leaving]
cyraxjoe has quit [Ping timeout: 265 seconds]
jmercouris has joined #lisp
<phoe>
do they know of the issue?
<jackdaniel>
technically it is not an issue
<jackdaniel>
being more resilent would be a feature
gigetoo has joined #lisp
<phoe>
well, if two different libraries can clash with each other by just using a single shared libgc then I'd say it's a real-world issue
<phoe>
specifically if the user wants to use these libraries and doesn't want to concern themselves with what they are using under the hood
<jackdaniel>
I don't share your opinion, but you are free to suggest such improvement
<p_l>
phoe: the classic solution in Windows world (where it's common to have conflicting dependencies that might not interact right) is to statically link such runtime dependencies into shared library and not reexpose them
<p_l>
kinda making the shared library into a closure
<phoe>
hah
hhdave has joined #lisp
brettgilio has quit [Ping timeout: 252 seconds]
karlosz has quit [Remote host closed the connection]
analogue has joined #lisp
nullniverse has joined #lisp
ggole has quit [Quit: Leaving]
ahungry has quit [Remote host closed the connection]
jmercouris has quit [Ping timeout: 258 seconds]
hhdave has quit [Ping timeout: 260 seconds]
xvx has quit [Quit: xvx]
analogue has quit [Ping timeout: 265 seconds]
cosimone has joined #lisp
whiteline has quit [Remote host closed the connection]
whiteline has joined #lisp
brown121408 has quit [Read error: Connection reset by peer]
brown121408 has joined #lisp
random-nick has quit [Ping timeout: 268 seconds]
retropikzel has quit [Quit: Leaving]
xvx has joined #lisp
pnp has quit [Remote host closed the connection]
vlatkoB has quit [Read error: Connection reset by peer]
<phoe>
froggey: "That said, if some Mezzano maven wanted to have ASDF tests run on Mezzano, they could "just" write some script that starts Mezzano in a new VM, with the ASDF directory magically mounted on the "same" path (and/or suitable paths copied in before the tests and copied out after them)."
<phoe>
that's from that asdf issue
random-nick has joined #lisp
patlv has joined #lisp
karlosz has joined #lisp
rippa has quit [Quit: {#`%${%&`+'${`%&NO CARRIER]
brettgilio has joined #lisp
karlosz has quit [Ping timeout: 265 seconds]
jfb4 has joined #lisp
jfb4 has quit [Remote host closed the connection]
ealfonso has joined #lisp
karlosz has joined #lisp
analogue has joined #lisp
mathrick has quit [Ping timeout: 260 seconds]
jfb4 has joined #lisp
xvx has quit [Quit: xvx]
jmercouris has joined #lisp
duuqnd has quit []
lavaflow has quit [Ping timeout: 265 seconds]
lavaflow has joined #lisp
whiteline has quit [Read error: Connection reset by peer]
whiteline has joined #lisp
narimiran has quit [Ping timeout: 240 seconds]
Jeanne-Kamikaze has quit [Quit: Leaving]
orivej has quit [Ping timeout: 265 seconds]
pfdietz28 has joined #lisp
orivej has joined #lisp
jmercouris has quit [Ping timeout: 268 seconds]
hhdave has joined #lisp
<Josh_2>
Hi, can anyone show me some more examples or an article anything really on the style used here? https://plaster.tymoon.eu/view/1633#1633 It took me a moment to figure out what was going on
jeosol has quit [Ping timeout: 260 seconds]
<phoe>
set-log-level should be (setf log-level)
<jackdaniel>
s/should/could/
xuxuru has joined #lisp
<jackdaniel>
(setf (log-level) :debug) ; looks weird, you setf log-level of /what/
<phoe>
hm
<phoe>
that's a compelling argument
<phoe>
s/compelling/guh I need to find the proper word
<Josh_2>
It's not originally my code, I just changed it slightly
<phoe>
oh! convincing
<pjb>
Josh_2: so what is it you don't understand?
<Josh_2>
Well I understand it now, I'm just curious whether this approach to the problem has a name
<jackdaniel>
Josh_2: that's basically how you would implement log levels (some parts could be phrased differently) -- I don't think it is complex enough to give it a name
<pjb>
Josh_2: I would have used a vector and an index, and mapped the keyword argument to (setf log-level) to this index to avoid the assoc…
<pjb>
Josh_2: you could call it caching of method.
<Josh_2>
pjb: see that's the sort of route I would have taken
<phoe>
same here
<phoe>
someone wanted to type it out explicitly though
<Josh_2>
jackdaniel: alrighty, I was just curious as it seemed very obscure to me
<jackdaniel>
note that there are two "entries", one is the current loglevel and the second is a message loglevel
<Josh_2>
Yes
<jackdaniel>
so verifying whether a message loglevel matches the current log level is not a keyword comparison but rather member for active levels
<jackdaniel>
phoe: member in set-log-level may be less efficient than ecase
<jackdaniel>
not that it matters much here
<phoe>
jackdaniel: hm, correct - that could be the reason why an ecase was chosen
<phoe>
it would get optimized to two jumps instead of list traversal
learning has joined #lisp
<phoe>
mayyybe if *debug-levels* was a constant... one could dream
<phoe>
oh well - less performant but somewhat more readable I hope
<scatterp>
hi i have an unformated lisp file and i am trying to view it in vim with formatting and rainbow mode when i enable the built in rainbow mode of vim it only highlights a few lines of the code can anyone help me with this?
<phoe>
this doesn't look like Lisp in the slightest
<phoe>
could you show me a screenshot of the beginning of the file?
<scatterp>
phoe, one moment
<pjb>
jackdaniel: (setf (level :log) :debug) ???
<scatterp>
phoe, that is the beginning of the file
<phoe>
pjb: (decf (level :sea)) ;; solves global warming
<phoe>
scatterp: this stuff doesn't look like Lisp at all
<scatterp>
phoe, i may be missunderstanding something i converted from ruby to s expression is that not lisp ?
<no-defun-allowed>
I think that is something like a dump of a Julia program. It's definitely not Lisp though.
<no-defun-allowed>
No, there are semantics attached and that is not Cambridge prefix either.
<scatterp>
ah ok
<phoe>
definitely not any kind of Common Lisp source
<no-defun-allowed>
You could open it in Emacs, select it all and use C-M-\ possibly.
<scatterp>
tried with emacs would not work
<scatterp>
let me see if i can find the correct channel ..
<scatterp>
hmm
<scatterp>
on google it says An s-expression, also known as a sexpr or sexp, is a way to represent a nested list of data. It stands for "symbolic expression," and it is commonly encountered in the Lisp programming language and variants of Lisp such as Scheme, Racket, and Clojure
<no-defun-allowed>
Yes, but those aren't s-expressions.
<scatterp>
ok let me check something one moment
shifty has quit [Ping timeout: 260 seconds]
<phoe>
this looks like Ruby source code
<phoe>
with all the "s(...)" calls
<no-defun-allowed>
It looks more like bytecode that's been disassembled after a second glance.
<phoe>
maybe the *result* of running this Ruby code will generate a S-expression
<scatterp>
yes so we started with a ruby file and then disassmbled it to "that"
<scatterp>
but as far as i understand that is sexp and its read back in to ruby using
<scatterp>
some ruby code which i can pastebin
<Shinmera>
ruby is off topic.
ealfonso has quit [Ping timeout: 252 seconds]
<no-defun-allowed>
No, those aren't s-expressions.
<no-defun-allowed>
Your code looks like :foo(bar, baz), but S-expressions look like (foo bar baz)
<scatterp>
i see
aindilis has quit [Remote host closed the connection]
hhdave has quit [Ping timeout: 240 seconds]
sabrac has quit [Ping timeout: 258 seconds]
<scatterp>
not to divert back to ruby because my point is to understand what this code is i understood it was lisp from this link http://timelessrepo.com/sexp-for-rubyists which sugests its lisp
<scatterp>
if its not it seems maybe its a close varient i mean its not c++ for sure..
<Shinmera>
Whatever the case it's not Common Lisp, so off topic.
<no-defun-allowed>
People can be wrong on the internet.
<no-defun-allowed>
And if someone complains about parentheses in the same post as they are explaining S-expressions, they are instantly unqualified to talk about them.
<phoe>
it looks much more like a case for ##lisp which is a general-Lisp channel; this one is strictly for Common Lisp, a particular dialect of Lisp
<scatterp>
ah!
<scatterp>
ok let me try there
<scatterp>
just to clarify because its really confusing for me...
<no-defun-allowed>
If you're putting out that code, and in Ruby, please don't.
<scatterp>
s-expressions is a way to express code in the language lisp but sexp is not a language ?
<no-defun-allowed>
Correct.
<no-defun-allowed>
And that parse tree isn't an s-expression.
<scatterp>
so confusing
<phoe>
no-defun-allowed: it actually is an S-expression, just represented in a way that is readable in Ruby.
<scatterp>
phoe my screenshot you mean ?
<phoe>
yes
<phoe>
a Lisp compiler will choke on it
<scatterp>
ruby lisp compiler accepts it (with the exception theres a bracket out of place)
<no-defun-allowed>
I guess it is a representation of symbols and arrays, but they don't follow S-expression syntax at all.
analogue has quit [Read error: Connection reset by peer]
<phoe>
no-defun-allowed: not the Lisp sexp syntax, correct
<phoe>
but then again, in this case, this looks much more like an emacs issue with rainbow-parens than anything else
<scatterp>
not quite phoe i have a story about that :)
<scatterp>
i tried to do rainbow with emacs for days with the support channel for emacs anyway multiple people worked with me on it and it didnt work out so thats how i ended up in vim tried in windows and linux also
<phoe>
If I open up emacs in ruby-mode with rainbow-parens active and then copypaste the snipper from the ruby article you posted, I get https://i.imgur.com/ufjlWt4.png - so stuff seems to work
<phoe>
well then, it seems like an issue with your editor setup - I don't think a channel dedicated to Common Lisp is going to be of much help to you
<scatterp>
in linux i installed a package called Rainbow (luochen) and it did the same as the image i sent finally i found out vim has support for rainbow built in enabled it thats the screenshot i sent you
<phoe>
in that case it'll be #vim
<scatterp>
yeah tried there thats why i came here i thought maybe language specific help might be better because its not just the colors its the formating and pretty printing i need to do but it seems if i understand correctly its an issue more for ##lisp
<phoe>
scatterp: #lisp can't help you with language-specific help if Common Lisp isn't the language
<phoe>
and it isn't
sabrac has joined #lisp
lavaflow has quit [Ping timeout: 260 seconds]
turona has joined #lisp
lavaflow has joined #lisp
longshi has joined #lisp
xuxuru has quit [Quit: xuxuru]
aindilis has joined #lisp
orivej has quit [Ping timeout: 268 seconds]
slyrus has joined #lisp
random-nick has quit [Ping timeout: 265 seconds]
zmt00 has joined #lisp
zmt00 has quit [Client Quit]
<galdor>
I'm wondering if there's a way to sort of wrap a condition into a new one: this way you get the information and context of the new one, but do not lose access to the stack trace and information of the first one
zmt00 has joined #lisp
<galdor>
a classic example would be when a low level routine signaled an error, but it was HANDLER-CASE catched at application level to indicate that something failed somewhere, and signaled as a new condition
learning has quit [Remote host closed the connection]
<galdor>
and if you do not do this kind of intercept + signal again, you end up without any context of what led to the error without decyphering the stack trace, which sucks for non-developers
<LdBeth>
galdor: then
<LdBeth>
when you get a condition
<LdBeth>
it is usually not the fault of the low level one
<LdBeth>
but you should check if wrong argument has been passed to the higher level interface, or you have a bug in your code
<LdBeth>
assume the low level one works all right
longshi has quit [Read error: Connection reset by peer]
<galdor>
sure if you have a bug in your code; but most errors I deal with are external data validation, system errors, things you cannot stop happening by calling functions differently
learning has joined #lisp
<galdor>
in that case, I want both to keep access to the original condition, its data and its stack trace, and wrap it to signal a high level error which will be more palatable (because a condition telling me "cannot read file foo.txt" does not help in any way)
<Bike>
galdor: if you use handler-bind instead of handler-case, the stack will not be unwound, so the trace is preserved
<Bike>
so you can signal your new wrapped condition from the handler.
<galdor>
ah this is true
<galdor>
this could work
<Bike>
lisp compilers, which are the most involved users of the condition system i know of, tend to do this
saravia has joined #lisp
<galdor>
yup it works perfectly well
varjag has quit [Quit: ERC (IRC client for Emacs 26.1)]