<paule32>
yitzi: #clschool they stop me discuss, because it is for beginners
<yitzi>
Most are not going to download zip files. If it is a single file then use a paste service. Or post a link to github or something like that if it is multiple files.
<paule32>
i have success in process for the lisp toy interpreter
<rotateq>
That would be new to me. But yes, hello paule32.
<Josh_2>
So what am I looking at?
taiju` is now known as taiju
<rotateq>
Josh_2: Maybe an advanced form of CLIM.
<paule32>
the actual state is: editor + (pre-alpha) parsers for lisp, dbase, and pascal + window form designer
SAL9000 has quit [Quit: WeeChat 3.4.1]
Bike has joined #commonlisp
<Nilby>
I like gui/form builders. I have used multiple form/app designers that used or generated Lisp. Lisp is natural for it because you can type an expression and have it run immediately in the model. And it has an easy data model. You can turn plists with lambdas into live objects.
<paule32>
you speak about LispWorks ?
trev has joined #commonlisp
Cymew has quit [Ping timeout: 276 seconds]
<Nilby>
No. A much older longer history. Mostly can't be run anymore without emulation. e.g. sk8 on old macs
<paule32>
text user interfaces are out of date ?
<Nilby>
people still love text UIs, and they're still useful, but I was talking about GUIs
<paule32>
my toy project is a gui application
Oddity has quit [Ping timeout: 255 seconds]
<paule32>
first, i would write a lisp interpreter, then i came to the point, to document the source code, but no suit desire help authoring tool was present, so i start docma as wordprocessor (still planing), then i came back to lisp, and would collect the world of other dsl together with lisp, a toying starting project is now on work
<paule32>
so, if the pre-alpha phase is over, i hope that the ffc procedure can be easy handled
<paule32>
but i dont promise anything
<paule32>
i have to check, and learn some internals of lisp
<Nilby>
Yes, but I'm not clear how it uses Lisp? Is implemented in Lisp? Does it interface to a Lisp like SLIME, or does just have a Lisp editing mode? A mini-Lisp as a DSL for writing application code?
<paule32>
completely other way
<paule32>
the source dsl for all is Pascal / Delphi code
<paule32>
thats why it is so very speed on
attila_lendvai has joined #commonlisp
<paule32>
the editor + form designer is completely pascal
<paule32>
the source code for lisp within this gui is handled by pascal
<Bike>
if this is not an implementation of common lisp it is off topic.
<Nilby>
sorry, I was just getting nostalgic for GUI builders actually in CL
<paule32>
Bike: if you talk to me: i would like to implement a common lisp derivat, i know that i can not name this product then as common lisp, but it is only for education for me, and should not be a commerical purpose or co.
<paule32>
when i doing new things, with new tools, then, that i learn between the gab of classic lisp, and new implementation
<paule32>
okay, this have not directly to do with lisp, but the dsl i toying should interpret lisp code
<paule32>
and, i will be free the final product as free to use without any fees
<paule32>
i try to hold me on Ansi compatible
<paule32>
and since common lisp is open source, and i could modified the source, i can feel free to do this
<paule32>
the other question is then, is this needed, or is the product acceptable to others, or do it some things that other product dont do
<paule32>
please dont worry, i am a hobby programmer, and i am not paid for this what i do, it is the interesst of retro computing
pranavats has left #commonlisp [Error from remote client]
<dieggsy>
how does lisp/the repl distinguish (values) and nil ? i see that putting (values) in an argument position converts it to nil, yet on its own at the repl it appears to return "nothing"
<beach>
When (VALUES) is in a context where a value is needed, it returns NIL. Otherwise, it returns no values.
<White_Flame>
the receiver can distinguish it with MULTIPLE-VALUE-LIST to get a list of all values, and seeing if it's empty
<beach>
It also works indirectly, so if you have (defun foo (...) ... (values)) and then you evaluate (foo ...) in a context where a value is needed, then NIL is used.
<dieggsy>
oh. well. heh, that makes sense. thanks
<White_Flame>
s/receiver/caller/
<dieggsy>
i guess how is that context determined? is that just up to the implementation
<beach>
No that's well defined.
<Bike>
it's defined by the language semantics
<Bike>
function calls expect one value. (multiple-value-bind (foo bar) ...) expects two
<dieggsy>
oh i see. I'm confusing myself with my own ambiguous language. the expected behavior is well defined, the specifics of how an implementation achieves said behavior is i assume up to them
<dieggsy>
thanks
aartaka has quit [Ping timeout: 258 seconds]
aartaka has joined #commonlisp
wmblathe_ has joined #commonlisp
wmblathers has quit [Ping timeout: 255 seconds]
<White_Flame>
if you're curious, in SBCL a singular value returns with clear carry & the value in a register. For other values, set carry and ECX = number of values, which are put in regs & the stack (but still sets the return reg to NIL on no value returns)
<White_Flame>
so a caller expecting a single value can ignore carry and just use the return value register either way
<White_Flame>
(this is on linux amd64)
<beach>
I wonder why it does both carry and ECX. Why not just always put the number of return values in ECX, which would then just be ignored in most cases?
<pjb>
it can be a side effect of the instructions choosen.
<beach>
What can be?
<pjb>
assembly programming is fun and magical for that.
<pjb>
the setting of the carry.
<beach>
But SBCL does it because it is specified.
<Nilby>
dieggsy: It's just that the REPL gets all the values and doesn't print anything if there aren't any values. But say (print (values)) has to get a value, so it's smushed NIL, by the implementation, like White_Flame says.
<pjb>
perhaps, but also, it may be specified because it's free in assembly.
<Nilby>
Registers are precious on many legacy architectures
<Nilby>
including the most popular one
<beach>
pjb: I don't see how it can be free in all situations.
<beach>
Nilby: So you are saying that when a single value is returned, ECX can be used for something else? How would that work?
<Bike>
maybe because a branch on the carry flag is very slightly cheaper than a branch on ecx being one
waleee has joined #commonlisp
<beach>
Bike: But if a single return value is wanted, then the carry flag does not have to be tested.
<beach>
So this would be an optimization for a caller wanting either 0 or more than one value, and the callee returns exactly one value?
<Bike>
right. it says in the internals document that it only does the branch when it's expecting something other than one value.
<Nilby>
i suppose you could know the carry should be use for something else
<Bike>
or rather, has to handle all values rather than just taking the primary
<beach>
Bike: But if something other than one value is expected, then the number of values has to be tested anyway.
<Bike>
ok, looking more closely now. i think the trick is that ecx (the number of values) is _not_ set by a single value return.
<Bike>
so in the caller, it branches on the carry, and if it's a single value return it sets ecx = 1 etc and then goes to the multiple value return code
<Bike>
"fakes up the register use convention of a multiple-value return" as the doc describes it
<beach>
But in the multiple value return that follows, the value of ECX must be tested anyway.
<beach>
So the test on the carry is extra.
<White_Flame>
the test on the carry is to see if ECX is holding the value count
<White_Flame>
if not, then it sets it to 1
<beach>
I understand that.
<Bike>
I mean, it's "extra" in the sense that there could be a different convention in which a single-value return did set ecx
<White_Flame>
if a caller expecting multiple values ends up calling a single-value return function, then that test is necessary
<Bike>
but it's not redundant in this convention. it does mean doing two tests
<beach>
My question is why this protocol is better, and if so in which situation?
<White_Flame>
I think this is a reasonable tradeoff for the common case of single-value returns & single-value expectant callers
<Bike>
well, it means a single value return doesn't have to do as much.
<beach>
How can the callee avoid either setting or clearing the carry flag?
<White_Flame>
clc/stc is a very inexpensive addition to the epilogue of all functions
<beach>
Less expensive than storing 1 in ECX?
<beach>
That's hard to believe.
<White_Flame>
yes
<White_Flame>
that's an expense of losing a register for all single-valued functions as well
<White_Flame>
(plus, it's a 2-byte instruction at least, instead of a single-byte clc)
<beach>
You don't lose a register. It can't be used for anything else to communicate from the callee to the caller, at least not what I can see.
<beach>
Ah, OK, so the number of bytes of instruction. That would be the optimization then.
<White_Flame>
mov ecx,0 is a 4-byte instruction
<White_Flame>
(at least in terms of what sbcl is generating)
<White_Flame>
erm, mov ecx, 2
<beach>
I am willing to accept the argument of the number of bytes in the instruction stream, but not any of the others (yet, at least).
<White_Flame>
sure, I'm not positive on the register pressure that that ecx use would have specifically
<beach>
... and I would be very surprised if this optimization would be noticeable at all.
<beach>
Did anyone try both ways and conclude that this technique actually makes a difference?
SAL9000 has joined #commonlisp
<White_Flame>
ECX is used by the caller to list the number of passed parameters, too, so yeah that's already committed by the caller anyway
<beach>
Sure. Either way, it couldn't be conditionally used to communicate anything form the callee to the caller. It would be available only if a single value is returned, so it couldn't be used for any additional values.
irc_user has joined #commonlisp
<White_Flame>
I'm not on the dev team, so I have no idea what they tried when making this optimizatino
<Bike>
if nothing else they were moving from a different convention that had more serious problems
<White_Flame>
I think that a count offset by 1 would be good here, so a returned ECX of 0 would indicate 1 return value and be short/quick to be in the epilogue
<White_Flame>
and the already more expensive multiple-value return handling just has to bump it a bit to get the real count of values
lisp123 has joined #commonlisp
<White_Flame>
the use of carry flag just takes that a step further, saves 1 byte on the common epilogue, and pushes a bit more on multi-value stuff
<paule32>
hello
<paule32>
the fasl files, they are text or binary images ?
<Josh_2>
did you try opening one?
<lagash>
`file <my.fasl>`
<Josh_2>
that'll tell you
lisp123 has quit [Ping timeout: 258 seconds]
Oladon has joined #commonlisp
pfd has joined #commonlisp
morganw has joined #commonlisp
prokhor__ has quit [Remote host closed the connection]
ttree has joined #commonlisp
cognemo has joined #commonlisp
kpoeck has joined #commonlisp
machaddr has joined #commonlisp
machaddr_ has joined #commonlisp
machaddr has quit [Ping timeout: 240 seconds]
machaddr_ has quit [Remote host closed the connection]
cognemo has quit [Ping timeout: 260 seconds]
molson has joined #commonlisp
cognemo has joined #commonlisp
pfd has quit [Quit: Client closed]
tyson2 has quit [Remote host closed the connection]
bitmapper has quit [Quit: Connection closed for inactivity]
molson has quit [Remote host closed the connection]
molson has joined #commonlisp
trocado has joined #commonlisp
molson has quit [Remote host closed the connection]
molson has joined #commonlisp
lisp123 has joined #commonlisp
machaddr has joined #commonlisp
molson has quit [Remote host closed the connection]
yagamisato has quit [Ping timeout: 246 seconds]
molson has joined #commonlisp
yagamisato has joined #commonlisp
yagamisato has joined #commonlisp
yagamisato has quit [Changing host]
lisp123 has quit [Ping timeout: 246 seconds]
machaddr has quit [Read error: Connection reset by peer]
cosimone has quit [Read error: Connection reset by peer]
knusbaum has joined #commonlisp
cosimone has joined #commonlisp
Guest74 has joined #commonlisp
pfd has joined #commonlisp
MajorBiscuit has joined #commonlisp
triffid has quit [Remote host closed the connection]
triffid has joined #commonlisp
MajorBiscuit has quit [Quit: WeeChat 3.4]
waleee has quit [Ping timeout: 255 seconds]
waleee has joined #commonlisp
dmgk has left #commonlisp [#commonlisp]
livoreno has quit [Ping timeout: 244 seconds]
morganw has quit [Remote host closed the connection]
yewscion has joined #commonlisp
brandflake11 has joined #commonlisp
<brandflake11>
Hey all, I'm writing code to generate drum beats, by putting functions into a list, that I then feed into a EVAL to activate in the right tempo. I wanted to know, is using EVAL bad practice?
random-nick has quit [Ping timeout: 246 seconds]
<mfiano>
Almost always.
<brandflake11>
mfiano: That's what I thought I had read from Paul Graham
<mfiano>
You cna map over the list and funcall.
<brandflake11>
If I were to call a function from a list into another function, is funcall a better function to use?
<brandflake11>
mfiano: Thanks so much for that link.
orestarod has quit [Ping timeout: 260 seconds]
X-Scale has quit [Ping timeout: 258 seconds]
<brandflake11>
One thing I'm a little confused about when using FUNCALL, is how to take a list with my function's arguments, and put that into FUNCALL.
<brandflake11>
I know it's probably a noob question
<brandflake11>
Would I have to use a macro to do that?
<mfiano>
You use APPLY for that
<brandflake11>
mfiano: I see, I'll look into that. I remember On-Lisp talking about this, but I have a hard time with that book
<mfiano>
Also there is #clschool for such language basics if you weren't aware. This channel generally assumes some fundamental knowledge.
<brandflake11>
mfiano: Yes, I'm sorry, I'll use that next time
X-Scale has joined #commonlisp
Oladon has quit [Quit: Leaving.]
X-Scale has quit [Ping timeout: 246 seconds]
X-Scale` has joined #commonlisp
X-Scale` is now known as X-Scale
<White_Flame>
if you're building up source code at runtime, then using EVAL, COMPILE, etc can be okay
dra has joined #commonlisp
<White_Flame>
if all you're doing is dynamically chaining a bunch of prebuilt function objects, then consider funcalling a list of them, or maybe use continuation passing style
dra_ has joined #commonlisp
Guest74 has quit [Quit: Connection closed]
dra has quit [Ping timeout: 260 seconds]
<phadthai>
then in-between where possible, there are macros, allowing to optimize code, if your lists/sequences don't change constantly
<phadthai>
and it still allows to occasionally update them by recompiling relevant sections