Colleen has quit [Remote host closed the connection]
CCDelivery has joined #lisp
<pjb>
static functions are private, you have no business calling them yourself!
karlosz has joined #lisp
atgreen has quit [Ping timeout: 240 seconds]
karlosz has quit [Client Quit]
karlosz has joined #lisp
karlosz has quit [Client Quit]
Oladon has joined #lisp
wusticality has joined #lisp
<aeth>
Meanwhile, in the CL universe, ::
<aeth>
A lot of languages take privacy more seriously than CL, though.
<Bike>
we also don't have linkage, so
<verisimilitude>
Erik Naggum's comparison of CLOS to C++ comes to mind.
<aeth>
Bike: There is a very similar concept with loading FASLs.
<Bike>
not really
<Bike>
a fasl is a sequence of actions
<aeth>
Bike: But if :: didn't exist then a private inlined function wouldn't need to exist in the FASL afaik.
<aeth>
(Of course, the function itself wouldn't be private, it would just be bound to a now-inaccessible assuming there was some way to do real package privacy... I guess not having :: isn't enough because there are a few other ways in CL.)
<aeth>
I wouldn't be surprised if the commercial CLs have some extension for this.
<fiddlerwoaroof>
It would be sort of cool if there were some way to open-code/inline a function and then reuse the inlined code for the general definition
<Bike>
there... is?
<verisimilitude>
What do you mean, fiddlerwoaroof?
<Bike>
you just declare the function inline
<fiddlerwoaroof>
e.g. the general definition gets a thing like "jmp to inlined location and execute this many instructions"
<aeth>
I thought open coding was more like type-based conditional inlining?
<fiddlerwoaroof>
My impression from older lisp stuff was that they're sometimes synonyms
<fiddlerwoaroof>
but /shrug
<verisimilitude>
I've had a similar idea, at the machine code level, but I don't see how that would be useful at a high-level for Common Lisp, fiddlerwoaroof.
<fiddlerwoaroof>
Maybe compilers already do something like this, I don't really know much about code generation
<fiddlerwoaroof>
verisimilitude: you'd only have to generate code once for a (declare (inline))'d function that's only used once
<fiddlerwoaroof>
Without losing the toplevel definition
<fiddlerwoaroof>
Hmm, you could probably do tricks with the MMU to get this to work
<verisimilitude>
By far the easiest way to get most of this is to simply avoid inlining altogether, fiddlerwoaroof.
<verisimilitude>
After all, one must account for the function being redefined.
<fiddlerwoaroof>
Sure, but that might be problematic for near-realtime systems like video games, flight control, etc.
<verisimilitude>
It's my opinion that, without a complex management scheme, it's best to optimize Common Lisp purely on functional boundaries, to avoid such issues.
<fiddlerwoaroof>
See, my favorite thing about CL is that it can be adapted to do a decent job for everything from the hardware up
<fiddlerwoaroof>
It's not like python where you have to lean on C for the performance-sensitive bits
<verisimilitude>
If you use a subset many problems melt away, yes.
Essadon has quit [Quit: Qutting]
fiddlerwoaroof has quit [Ping timeout: 246 seconds]
ioa has quit [Ping timeout: 246 seconds]
fiddlerwoaroof has joined #lisp
funnel has quit [Ping timeout: 246 seconds]
funnel has joined #lisp
plathrop has quit [Ping timeout: 246 seconds]
eagleflo has quit [Ping timeout: 246 seconds]
eagleflo has joined #lisp
quazimodo has joined #lisp
plathrop has joined #lisp
quazimodo has quit [Ping timeout: 240 seconds]
<buffergn0me>
Does anyone have recommendations for a code walking library that handles environments correctly?
<buffergn0me>
(not trying to do code walking or recommend that anyone does it, I just want to see how it works)
quazimodo has joined #lisp
anewuser has joined #lisp
quazimodo has quit [Ping timeout: 245 seconds]
marusich has joined #lisp
quazimodo has joined #lisp
markoong has quit [Quit: Konversation terminated!]
quazimodo has quit [Ping timeout: 246 seconds]
akoana has left #lisp ["Leaving"]
<LdBeth>
couldn't xref do that?
anewuser has quit [Ping timeout: 245 seconds]
<verisimilitude>
I believe ITERATE contains a code-walker, buffergn0me, so take a look there.
anewuser has joined #lisp
<no-defun-allowed>
According to the table on http://norvig.com/Lisp-retro.html, CL exception handling is faster than C++. How do CL implementations make it that fast?
<Bike>
um, it's complicated, but as someone working on the C++ lisp implementation i could take a guess
<verisimilitude>
For one, the stack doesn't necessarily unwind, no-defun-allowed.
<no-defun-allowed>
Right.
<Bike>
the basic thing is that due to C++'s RAII tendencies, almost every stack frame is kind of an unwind protect
<verisimilitude>
Also, I figured being an amalgamation of shitty ideas, C++ would have more that stands in the way of an efficient exception mechanism mixing with everything else, yes.
<no-defun-allowed>
Gotcha, thanks.
wusticality has quit [Ping timeout: 244 seconds]
<verisimilitude>
It's my understanding there's so-called ``zero-cost exceptions'', that only impact things when used, but do so gravely in that case.
<Bike>
it also increases code size, i think
<Bike>
but i haven't looked too far into it
marusich has quit [Ping timeout: 250 seconds]
phoe has quit [Ping timeout: 240 seconds]
wusticality has joined #lisp
marusich has joined #lisp
wusticality has quit [Ping timeout: 268 seconds]
atgreen has joined #lisp
<buffergn0me>
I look at that as another case where garbage collection is more efficient than manual memory management (in this case, destructors)
emaczen has quit [Ping timeout: 240 seconds]
keep_learning_M has joined #lisp
wusticality has joined #lisp
iovec has joined #lisp
milanj has quit [Quit: This computer has gone to sleep]
wusticality has quit [Read error: Connection reset by peer]
wusticality has joined #lisp
marusich has quit [Remote host closed the connection]
Necktwi has quit [Read error: Connection reset by peer]
dddddd has quit [Remote host closed the connection]
CCDelivery has quit [Remote host closed the connection]
lemoinem has quit [Ping timeout: 272 seconds]
lemoinem has joined #lisp
Necktwi has joined #lisp
marvin2 has quit [Ping timeout: 250 seconds]
<fiddlerwoaroof>
The benefit of RAII is not that it's necessarily more efficient than a GC but that it's more predictable
<fiddlerwoaroof>
You just don't let destructors run until you're ready to take a pause to free used memory.
<djeis[m]>
Or run finalizers on any random thread that happens to be handling the GC...
<fiddlerwoaroof>
yeah
<fiddlerwoaroof>
Although, my impression is that Java discovered that finalizers are sort of a bad idea because of predicatability issues
<buffergn0me>
finalizers in a GC is a fundamentally broken concept
<buffergn0me>
GC should handle memory, not other arbitrary resources. That's what UNWIND-PROTECT is for
<no-defun-allowed>
finalizers with cheney sounds like it'd lose all the benefits of copying
<djeis[m]>
RAII conflates the two tho.
<buffergn0me>
which is part of the problem with C++
<djeis[m]>
#'no-defun-allowed: Well, you could just do another pass over the from space to finalize all of the new garbage.
<buffergn0me>
Also any copying and any non-braindead mark-and-sweep GC is going to be more efficient than destructors because it does not have to do any work on the dead objects. The only reason for destructors is to traverse dead objects
<no-defun-allowed>
Which is O(dead), thus tossing out the benefits of Cheney.
<buffergn0me>
Of course you are right that efficiency can mean latency or throughput
jkordani has quit [Read error: Connection reset by peer]
<djeis[m]>
That's not the only benefit of Cheney
<fiddlerwoaroof>
buffergn0me: the problem with a gc in some applications is that you generally can't easily control where the pauses happen
<djeis[m]>
Compacting is its own reward.
<no-defun-allowed>
That's true.
<djeis[m]>
Plus, that last loop is sequential.
<djeis[m]>
And doesn't involve a ton of logic, apart from what's actually in the finalizers.
<djeis[m]>
And if you're clever you could probably make it proportional to only the dead items that actually have finalizers.
<no-defun-allowed>
Also true.
<djeis[m]>
Still, as was mentioned, finalizers are a broken concept for other reasons.
amerlyq has joined #lisp
<no-defun-allowed>
Yep.
amerlyq has quit [Client Quit]
<buffergn0me>
fiddlerwoaroof: True. Bounded low-latency GC only exists in a few JVMs now.
themsay has joined #lisp
<fiddlerwoaroof>
I'm sort of hoping projects like Shenandoah and ZGC make it more widely available, even if only on the JVM
<beach>
Good morning everyone!
<no-defun-allowed>
morning beach!
wusticality has quit [Ping timeout: 250 seconds]
FoxyBoxes has quit [Quit: Using Circe, the loveliest of all IRC clients]
wusticality has joined #lisp
elem6 has quit [Ping timeout: 268 seconds]
elem6 has joined #lisp
elem6 has quit [Ping timeout: 240 seconds]
wusticality has quit [Ping timeout: 272 seconds]
Bike has quit [Quit: Lost terminal]
Necktwi has quit [Quit: leaving]
<no-defun-allowed>
oh, while we're not too far off GC talk, is there a non-recursive mark-sweep system?
nikkal has joined #lisp
<no-defun-allowed>
m-s is easier to do incrementally, but you need a stack last time i checked
emaczen has joined #lisp
<beach>
There is a technique called "pointer reversal" that can do it iteratively, but it is unattractive in that it modifies the object graph as it goes along.
<beach>
It is also possible to keep an explicit stack.
<beach>
One technique uses a fixes-size stack and just gives up and restarts when the stack overflows.
wxie has joined #lisp
<beach>
Oh, and you can use the three-color method without recursion.
<beach>
Keep a bitmap with two bits for each object.
<beach>
An object can be write (not found yet), gray (found and marked, but may have white successors), or black (marked with no white successors).
<beach>
can be white, I mean.
<beach>
The marking algorithm consists of finding any gray object, coloring any white successors of it gray, and then coloring the object itself black.
<beach>
It is tricky to do the "find any gray object" efficiently.
<beach>
Again, one possibility is a fixed-size "gray set".
<no-defun-allowed>
Right, thanks.
<beach>
As long as there is room in the set, you can just pick a gray object in the set.
<beach>
If it ever overflows, you note that event, so that when the gray set is empty, you have to find a more expensive method to find another gray object.
<beach>
That way, you don't have to buy the book "The Garbage Collection Handbook" by Jones.
<emaczen>
I've loaded all objc methods into defuns that call the appropritate GNUstep runtime C functions, and currently objc classes into a lisp metclass I defined with a ptr slot to hold the foreign pointer.
<emaczen>
I'm looking for suggestions for how to implement the metaclass
<emaczen>
I don't have any real experience with the MOP other than code inspection
elem6 has joined #lisp
<no-defun-allowed>
My school has a very small collection of programming books, and the GCH was in it. Must have been a hand-me-down.
<emaczen>
Is wrapping the pointer the right approach?
drl has joined #lisp
elem6 has quit [Ping timeout: 250 seconds]
sauvin has joined #lisp
Oladon has quit [Quit: Leaving.]
sauvin has quit [Excess Flood]
<fiddlerwoaroof>
emaczen: I think so, but it depends what you're trying to do
<fiddlerwoaroof>
Are you still getting the function pointer out of the class to invoke a method?
<emaczen>
I defined all objc methods as defuns taking an argument for the object or class name (depending on if the method is an instance method of class method) and then used the runtime to determine the additional parameter types.
<beach>
no-defun-allowed: That's great! It's a book that contains all the information that you need, but it is very badly written, unfortunately. Wilson is a much better writer.
<emaczen>
The function then uses the runtime to get the method etc and finally uses #'cffi:foreign-funcall-pointer to call the method
<no-defun-allowed>
I see.
<beach>
no-defun-allowed: I am saying that because, in case you read some part and do not understand it, it is very likely not your fault.
<fiddlerwoaroof>
emaczen: Are you decoding the result of method_getTypeEncoding
<fiddlerwoaroof>
?
<no-defun-allowed>
The diagrams helped me understand Cheney semispace copying collectors, at least.
<beach>
no-defun-allowed: Sure, like I said, it contains all the information you need.
<beach>
But Wilson's paper is more pleasant to read. Unfortunately, it is getting old, so many new techniques are not covered.
<no-defun-allowed>
I think most of the book is still over my head, which is not the book's fault.
<beach>
There is that, sure.
<emaczen>
No, I used method_copyReturnType, method_getNumberOfArguments, and method_copyArgumentType
<beach>
I had the great pleasure to work with Paul Wilson and his group at UT Austin for a year.
karlosz has joined #lisp
<fiddlerwoaroof>
emaczen: cool, I've been punting on that for the code I've been writing to bridge objc/lisp
<no-defun-allowed>
Nice.
<emaczen>
fiddlerwoaroof: I never looked at method_getTypeEncoding, it might be the same information just returned all at tonce
<fiddlerwoaroof>
it is
<fiddlerwoaroof>
I think it's what CCL uses
<no-defun-allowed>
Actually, the librarian did ask me for programming book reccomendations a few years ago. Maybe they ordered some of them.
<emaczen>
fiddlerwoaroof: How far along are you?
<fiddlerwoaroof>
I've gotten an entire mac app to work
<fiddlerwoaroof>
But, my strategy is really different from yours, I think
<beach>
no-defun-allowed: That's very good. Many librarians constantly look for recommendations, and few people help out. It is a fantastic opportunity to work with librarians to get a good collection.
<emaczen>
fiddlerwoaroof: I just want to get a few CCL programs that I wrote to work on GNUstep
<fiddlerwoaroof>
Are you using CCL on linux?
<beach>
no-defun-allowed: When I was in charge of the CS department here, I appointed one of my young colleagues to be the library liaison. He did a fantastic job, so we got a great CS collection of books.
<emaczen>
SBCL currently
<beach>
no-defun-allowed: He also went through their existing collection and had about 50% removed as old and obsolete.
<emaczen>
Actually, I want that to be a criteria too
<no-defun-allowed>
Wow.
<emaczen>
fiddlerwoaroof: I'll probably run into some problems with the type encodings... but I think most of it will work since CFFI just uses :pointer
<fiddlerwoaroof>
emaczen: Hmm, I've thought of porting CCL's objc layer, but I actually like making the objc-interop stand out
<fiddlerwoaroof>
The main issue I've run into is methods that expect structs passed by value.
<emaczen>
fiddlerwoaroof: I got cffi-libffi to work
<fiddlerwoaroof>
interesting, do you have code you want to share?
<emaczen>
wait
<emaczen>
I don't think I have even tried with methods, only C functions like NSMakeRect
<fiddlerwoaroof>
hmm, initWithContentRect:?
<emaczen>
Give me an example and I'll test it out real quick
<emaczen>
Ok, give me as ec
<emaczen>
I have a strange problem loading everything initially, but I'm loading all the methods now
<emaczen>
then I can try
phoe has joined #lisp
<emaczen>
fiddlerwoaroof: I think it worked?
<emaczen>
My lisp crashed because I didn't create an autorelease pool
<emaczen>
or a sharedApplication
<fiddlerwoaroof>
That's something else I've been punting on
<fiddlerwoaroof>
I haven't been able to figure out how to handle runtime errors
<emaczen>
But I really think the method call works because I wrote a function that draws a window to the screen only using the C libraries via CFFI and I created an Autorelease pool and a sharedApplication before the window, and there isn't any real difference between that manual test code and my macro expanded defun forms
<emaczen>
I'll try an autorelease pool real quick I guess
<fiddlerwoaroof>
I've gotten weird errors where I think I've done everything right, but it doesn't work
<emaczen>
But yeah, I need to look at handling the runtime errors so I don't have to keep loading all 8,000 methods!
<fiddlerwoaroof>
I don't bother trying to preload the messages
<emaczen>
I macroexpand defun forms that call the runtime library -- I should probably write the defun forms to files
<fiddlerwoaroof>
If you use objc_msgSend, you just need a selector and the arguments
<fiddlerwoaroof>
The complicated thing is you have to pick the right msgSend for the return type
guicho has joined #lisp
<emaczen>
fiddlerwoaroof: #/initWithContentRect:styleMask:backing:defer: worked after making an autorelease-pool
<emaczen>
and a sharedApplication
<fiddlerwoaroof>
cool
<fiddlerwoaroof>
do you happen to know what I need to think about as far as memory management goes?
<fiddlerwoaroof>
if i have an autoreleasePool, does everything happen automatically?
<emaczen>
fiddlerwoaroof: With my experience using CCL NO
<emaczen>
I don't think it is too bad though
<emaczen>
I just had a bad experience becuase I wrote a bunch of UI utility code without ever considering the memory leaks, and then when it mattered I couldn't find my bug
<fiddlerwoaroof>
:)
<emaczen>
I might try the C beohm garbage collector when I get to that point
<fiddlerwoaroof>
I think if you register the objc objects with the autorelease pool correctly, it should take care of itself
<fiddlerwoaroof>
but there's a little issue of keeping them alive from lisp
<emaczen>
So I just drew the window that I created with #/initWithContentRect:styleMask:backing:defer: and then shortly thereafter I get a message from my OS that says GNUstep isn't responding etc...
<emaczen>
I'm guessing this a threading issue? Have you ever dealt with that?
<fiddlerwoaroof>
cocoa expects to be in the main thread
<fiddlerwoaroof>
I think Shinmera has a library called trivial-main-thread
<fiddlerwoaroof>
that handles this
<emaczen>
fiddlerwoaroof: What is the "main thread" here?
<no-defun-allowed>
the first thread created?
<emaczen>
I'm familiar with what cocoa expects (in CCL you call #'gui::execute-in-gui I think)
guicho has quit [Ping timeout: 246 seconds]
<no-defun-allowed>
also, i'd presume there's some kind of refresh required idk
<fiddlerwoaroof>
emaczen: yeah, the first thread created
<fiddlerwoaroof>
other than that, I think the os automatically gives that thread an event loop
<emaczen>
fiddlerwoaroof: It must be accessible from the NSApp object I'm guessing
<fiddlerwoaroof>
That is, I don't need to do anything else
<fiddlerwoaroof>
Yeah, it just looks like [objc-runtime::ns-app @(run)]
<emaczen>
I called (#/makeKeyAndOrderFront: win (cffi:null-pointer))
<emaczen>
It drew the window, and then I got the error
<emaczen>
The error is just in my OS too, lisp didn't crash and I didn't get any exceptions
<beach>
no-defun-allowed: If you go for this project, you need to decide whether to support both the British and the American approach.
<beach>
If you only support one, I suggest the American approach.
<beach>
no-defun-allowed: The different account categories listen on that page will be excellent superclass names for the accounts of the application.
<fiddlerwoaroof>
emaczen: I also got nib loading to work...
<no-defun-allowed>
I did read that page, but I don't understand how it handles external money flow, if it does.
<beach>
no-defun-allowed: listed on that page, I mean.
<no-defun-allowed>
Ah, there are 5 accounts which complement each other in some way.
<beach>
no-defun-allowed: You mean when you pay a bill for example?
<no-defun-allowed>
Yeah, or when you get paid.
<emaczen>
fiddlerwoaroof: Is this main thread accessible from lisp or just the OS?
<emaczen>
Or cocoa?
<no-defun-allowed>
But I see that's accomplished by "moving" funds from one account to another.
<beach>
no-defun-allowed: OK, short lesson: When you receive a bill, you incur a COST to the organization. Actually, the cost happens when you use the resource (like make a phone call), but usually it is considered to happen when you receive the bill.
<no-defun-allowed>
Right.
<beach>
When that happens, you debit one account and credit another.
<beach>
I need to think of which one...
<no-defun-allowed>
Expences incrementing and Capital decrementing sounds about right.
<emaczen>
fiddlerwoaroof: Do you know why CCL doesn't support nib loading?
<beach>
One is the cost account (telecom or electricity) and one is a liability account (you owe the phone company).
<no-defun-allowed>
I see.
<fiddlerwoaroof>
emaczen: I think it does, if it doesn't, it's pretty simple to do
wusticality has joined #lisp
<beach>
no-defun-allowed: Right, I said "cost" but I meant expenses.
<fiddlerwoaroof>
You need to create a delegate that responds to the expected selectors and then call @(initWithNibNamed:bundle:) on #@NSNib
<beach>
no-defun-allowed: So you debit the expenses account and credit the liabilities account.
<no-defun-allowed>
No problem. Liabilities were on the list, too.
<beach>
no-defun-allowed: Then when the bill is actually paid, i.e. when the money is deducted from your bank account, you debit the liabilities account and credit the bank account.
<no-defun-allowed>
I understand that now.
<beach>
The inverse happens when you have some revenue.
<no-defun-allowed>
Gotcha.
<beach>
When you sign the contract with your customer, you credit the revenue account and debit the assets account.
<beach>
etc, etc.
* no-defun-allowed
nods
<beach>
It's very simple really.
<no-defun-allowed>
Yes, it does sound quite simple.
<beach>
Things get a bit more complicated by things like sales tax.
<beach>
Or other taxes for that matter.
wusticality has quit [Ping timeout: 246 seconds]
<beach>
Like, when you get the phone bill, only part of the expenses go to the telecom account. Others go to the tax account.
<beach>
If you have a presentation to do as part of the project, an excellent introduction would be to spend a few minutes on double-entry bookkeeping.
<beach>
Certainly, in the report.
<no-defun-allowed>
I do have to write a lot of documentation, so it would definitely be good to include.
<beach>
Great!
<beach>
no-defun-allowed: The secret to a simple application is to realize that you never have to store account balance. You just have to store the transactions sequentially, and compute the account balance on the fly.
<beach>
That's why my existing application is so short.
<no-defun-allowed>
That would work well.
<beach>
So most people will now protest and say something like "Oh, but that will be horribly slow".
<no-defun-allowed>
Yeah, about that...
<beach>
So part of your report/presentation should include a back-of-envelope calculation that shows that it is fast enough even for a large corporation.
<no-defun-allowed>
My teacher said I had to include some sort of "algorithm", so I was thinking that an in-memory AVL tree for caching most of the calculations would be interesting.
<no-defun-allowed>
Hah, it probably would be.
<beach>
So, that's the typical reaction of someone who hasn't done the back-of-envelope calculation.
drot has quit [Ping timeout: 268 seconds]
<beach>
no-defun-allowed: Say you do a transaction per minute 24/7. That would be 0.5 million per year. Suppose 100 years of accounting. That would be 50 million transactions. This will take a few milliseconds to traverse.
<beach>
no-defun-allowed: To see whether this is reasonable, you can figure out how many employees would be required in order to fill the system at that rate, and you have a good idea of how large a corporation you can handle.
drot has joined #lisp
<beach>
no-defun-allowed: I mean, only a small fraction of the employees would do data entry, or else the company would get nothing done.
<no-defun-allowed>
I agree it would be negligible, but the rubric suggests I should "organise and manipulate all data through the efficient and effective use of appropriate data structures".
<beach>
OK, so then you have to pretend that an inappropriate data structure is actually appropriate. Sad, but true.
<beach>
I am not terribly surprised though.
<beach>
The story of my life.
<no-defun-allowed>
Again, that does sound like it would be very fast for the user, but I think I am expected to be a bit more aggressive with my choices in a way.
<no-defun-allowed>
On the other hand, we only cover arrays and hash-tables at school, so they may not be able to remove marks for using a list.
sauvin has joined #lisp
<beach>
I fully understand. Like I said, I am used to it.
<beach>
We can discuss this later.
<beach>
One option would be to use a list, but sketch a solution for huge corporations.
<no-defun-allowed>
Of course.
<beach>
Oh, I think I have some ideas.
<beach>
Rather than storing account balances, compute them (as I indicated) when the user logs in, and keep them in memory. New transactions will then result in incremental updates to the account balances in memory, but still not stored.
sauvin has quit [Excess Flood]
<beach>
Anyway, premature stuff.
sauvin has joined #lisp
atgreen has quit [Ping timeout: 250 seconds]
<no-defun-allowed>
Kinda sidetracking, does the CLIM interactor support Emacs-y shortenings of commands? Say if I had a command "Add Transaction", could I enter "a t" or whatever string that has the shortest unique prefixes of the command?
<fiddlerwoaroof>
no-defun-allowed: space completes unambigous prefixes
<no-defun-allowed>
Ooh, wonderful.
pritambaral has quit [Ping timeout: 246 seconds]
<no-defun-allowed>
I think I could add that to my report when the time comes, as experienced users could just use memorised prefixes to speed up entry, compared to clicking the UI buttons or typing the full command.
<fiddlerwoaroof>
Yeah, or keyboard shortcuts/etc.
akater has quit [Quit: WeeChat 2.3]
akater has joined #lisp
anewuser has quit [Quit: anewuser]
themsay has quit [Ping timeout: 244 seconds]
<beach>
no-defun-allowed: Yes, CLIM is great with that kind of stuff. Most of it is entirely automatic.
<no-defun-allowed>
fiddlerwoaroof: Most shortcuts aren't very easy to memorise. For example, C-x, C-c and C-v are only memorable because they are in a row on QWERTY/Z keyboards.
<emaczen>
What is the primitive method of running a function inside of an existing thread?
<no-defun-allowed>
Something like "a t" is easier to remember, and CLIM gives you feedback through when it expands.
<no-defun-allowed>
Erm, there was something in bordeaux-threads about interrupting threads.
<emaczen>
no-defun-allowed: What about just sb-thread
elem6 has joined #lisp
<no-defun-allowed>
(BT:INTERRUPT-THREAD thread function &rest args) funcalls function with args on the thread thread
<no-defun-allowed>
emaczen: Do you want a CL program or a SBCL program?
<no-defun-allowed>
BT is not in the CL standard, but it's a hellofalot more portable than sb-thread.
wusticality has joined #lisp
<emaczen>
I don't have bordeaux-threads loaded right now
<emaczen>
There is sb-thread:interrupt-thread
<no-defun-allowed>
Well, load it please.
<no-defun-allowed>
sb-t:interrupt-thread is the same as the b-t function, except it doesn't take funcall arguments. I assume it uses a small wrapper for that.
<emaczen>
Can you just call this function and expect your threading code to work?
<no-defun-allowed>
I remember it resumes normal execution after your interrupt is done.
<chrnybo>
I've got some plists, want the library yason to encode them as plists, so I've defined an around-method on yason:encode that calls encode-plist when arg is apporpriate, and call-next-method otherwise.
<chrnybo>
This alters the global behaviour of yason:encode, which can be seen as impolite.
<chrnybo>
Alternative approaches?
<ggole>
Write your own generic function that does the plist thing when you want and falls back to yason:encode otherwise?
q9929t has joined #lisp
q9929t has quit [Read error: Connection reset by peer]
wusticality has quit [Ping timeout: 246 seconds]
<chrnybo>
For top level, that would work, but wouldn't cover nested plists such as:
<chrnybo>
"Try another json library 'till it does what you want" is probably good advice.
void_pointer has joined #lisp
<ggole>
Oh right, you won't be able to fall back to yason:encode because it won't call your function on nested parts. It's the open recursion problem again.
wxie has joined #lisp
<loke>
chrnybo: doesn't Yason do that? But you should type it as '((:foo . 1) (:bar . #((:zot . 12))))
nowhere_man has quit [Ping timeout: 252 seconds]
<chrnybo>
loke: My version of yason does not seem to like such conses.
wxie has quit [Ping timeout: 244 seconds]
<chrnybo>
ggole: I let a flag variable and declared it special, then I check for that flag in my around method. Thus I can leave other users of yason:encode undisturbed.
<_death>
why do you declare *lists-as-plists* as special? did you not defvar/defparameter it?.. and if not, you should also declare it special in the :around method
<chrnybo>
No, no defvar/defparameter of it. I'll do that.
<_death>
btw, interesting.. didn't know Telenor used CL
elem6 has joined #lisp
<chrnybo>
_death: Described in a paper by Espen Vestre published at a japanese lisp conference
CCDelivery has quit [Remote host closed the connection]
wusticality has joined #lisp
notzmv has quit [Ping timeout: 246 seconds]
hiroaki has joined #lisp
nowhere_man has joined #lisp
wusticality has quit [Ping timeout: 240 seconds]
hiroaki has quit [Ping timeout: 240 seconds]
themsay has joined #lisp
akoana has joined #lisp
chrnybo has quit [Ping timeout: 245 seconds]
FreeBirdLjj has quit [Remote host closed the connection]
Kundry_Wag has joined #lisp
scymtym has quit [Ping timeout: 240 seconds]
hiroaki has joined #lisp
asarch has quit [Quit: Leaving]
Oladon has quit [Quit: Leaving.]
orivej has joined #lisp
zigpaw has joined #lisp
elem6 has joined #lisp
Oladon has joined #lisp
random-nick has quit [Ping timeout: 246 seconds]
Kundry_Wag has quit [Remote host closed the connection]
Kundry_Wag has joined #lisp
Kundry_Wag has quit [Remote host closed the connection]
lumm_ has joined #lisp
lumm has quit [Ping timeout: 240 seconds]
lumm_ is now known as lumm
random-nick has joined #lisp
ggole has quit [Quit: Leaving]
benkard has joined #lisp
mulk has quit [Ping timeout: 268 seconds]
benkard is now known as mulk
kenu has quit [Remote host closed the connection]
Kundry_Wag has joined #lisp
wusticality has joined #lisp
<fiddlerwoaroof>
akater: I noticed you were talking about class redefinition issues the other day, CL has UPDATE-INSTANCE-FOR-REDEFINED-CLASS that can sometimes help.