freenode/lisp - IRC Chatlog
Search
18:29:57
rmrenner
I just hit another snag with parenscript. The docs say that random is a reserved word and shouldn't be used to name things. Fine, except it turns out that p5.js defines a function called "random" with different semantics than the one provided by parenscript
18:33:11
rmrenner
Is there a way to get parenscript to treat (random 1 2) as just another function? As-is, it throws a fit because the version it defines only takes one argument
18:42:05
vtomole
How does asdf load files? I'm calling a function that is defined in a different file and lisp is not able to find it even though i used a "depends-on" tag.
18:44:21
rmrenner
parenscript's default behavior is that (random) => "Math.random();" and (random 6) => "Math.floor(6 * Math.random());"
18:44:55
White_Flame
:serial t is IMO the simplest way to list your files, instead of individual dependencies
18:45:46
rmrenner
So I'd like to be able to type (random 1 2) and get "random(1 2);" --the "random" defined by p5.js behaves differently
18:47:21
White_Flame
can you make a little stump function in js, var p5random = (x,y) => random(x,y); ?
18:49:16
sausages
in SBCL, if a foreign function causes an exception, what are my options in finding out the actual name of that problem function and the .dll it came from? SBCL's debugger just prints them as nebulous hexadecimal pointers in the backtrace
18:50:03
vtomole
White_Flame: The function that is called in braiding.lisp is defined in qgame.lisp: http://paste.lisp.org/display/349435
18:50:53
rmrenner
Nice, ((@ document random) 1 2) seems to work. And the way it was phrased made me realize that (ps (funcall random 1 2)) => "random(1, 2)"
18:51:10
White_Flame
other than that, did you forget an in-package on top of your files or something?
19:01:08
White_Flame
and then you ask questions about those tools, which distract from your actual problem
19:05:19
rmrenner
woo ok so now I have a nice solution to calling p5.js's version of random: (defmacro rnd (&rest args) `(funcall random ,@args))
19:06:18
_death
but I believe the converse is true, you can have multiple initargs for a single slot..
19:07:36
aeth
drmeister: The implementation of quaternions varies greatly, though. e.g. I use multiple return values most of the time.
19:09:34
specbot
Rules for Initialization Arguments: http://www.lispworks.com/reference/HyperSpec/Body/07_ad.htm
19:12:12
vtomole
drmeister: You've done some work on Jupyter notebook. Have you ever run into a situation where you needed to call python from lisp? A python cffi of some sort?
20:49:33
rmrenner
So yesterday I asked whether it was possible in parenscript, to prevent ps from blindly sticking a "return" before the final statement/expression in a function
20:49:55
rmrenner
The answer: no. And today that "feature" just introduced its first bug! I love software
20:52:09
rmrenner
It does, but for a relative js novice, it's only obvious when you need to take that extra step when something breaks
20:53:48
Bike
i haven't used parenscript much, but i think it's supposed to compile some lisp-like language to javascript, so it beahves like lisp
20:57:39
rmrenner
Yeah, it's Mostly Lisp. I'm fairly impressed with most of the things it does, but sticking points like the "return" issue I'm finding frustrating.
20:59:08
Grue``
if I make a http request that sends a file within pcall:pcall it produces 400 Bad Request error, but otherwise the same request produces 200 OK https://pastebin.com/raw/UUpjHLZE
21:02:01
specbot
compute-applicable-methods-using-classes: http://metamodular.com/CLOS-MOP/compute-applicable-methods-using-classes.html
3:31:03
vtomole
beach: Saturday night hacking lisp, couldnt get any better. Making some progress on the allocator paper too
3:51:47
vtomole
beach: I still need to hear an opposing viewpoint to this. Garbage collection protects you from "shooting yourself in the foot", but there are reasons why new languages that don't have automatic memory management are still being created.
3:55:39
beach
vtomole: I think the way to go is to use a concurrent and incremental garbage collector. That way, it would be possible to take advantage of processors with multiple cores as well.
3:57:02
White_Flame
right, most larger systems tend to build up a runtime of their own that isn't going to be as good as what you get from language-supported features
4:00:38
beach
vtomole: There are three different issued here, and they are mostly orthogonal. One is overhead. There GC wins no problem. Implementing malloc() and free() efficiently is very hard. The second issue is real-time. This one is tougher, because a real-time GC does have more overhead than a non-real-time GC.
4:00:42
beach
But then, you don't get real-time automatically with malloc() and free() either, because of the complex data structures that have to be maintained. The final issue is development and maintenance cost.
4:00:44
beach
It is known that not using GC increases that cost a lot. In fact I have seen projects that were canceled after a few million Euros were spent, just because they couldn't simultaneously create a modular system and one that did free() at the right time.
4:01:39
White_Flame
both malloc and free have arbitrary data shuffling & maintenance they might do per call, so they're usually far from predictable performance
4:02:30
beach
But it is common for (not so knowledgeable) developers to believe that malloc() and free() behave in predictable ways.
4:05:43
vtomole
beach: Reading this paper, it seems like a developer would want his/her language to support multiple types of garbarge collectors; So the user can pick one based on the goal.
4:05:56
beach
vtomole: More generally, you should be aware that phrases like "we need all the speed we can get", or "we need absolute bounded response times" really mean "we are willing to spend any amount of additional development and maintenance time for even a minuscule improvement in performance (or to get bounded response)". Only when they realize that this kind of additional money is not available, it is too late and the project is canceled.
4:06:24
White_Flame
vtomole: ideally, the system would measure & detect which GC strategy would be most effective. It can be incredibly difficult to manually predict properly
4:07:29
White_Flame
and different strategies woudl apply to different data, not just 1 GC for all of memory
4:07:48
beach
vtomole: Yes, that would be nice. But we are in the business of free software (which is why we are on freenode) and already implementing a single bug-free GC is hard. Implementing multiple ones, some of which are real-time, is extremely hard, and we don't have the manpower.
4:09:44
White_Flame
GCs also don't stand alone. The readers/writers in the code need to manipulate them in certain ways, obey different views of safepoints, etc
4:09:46
beach
vtomole: There are a few branches of industry that can afford such additional manpower. Weapons, nuclear power, medical equipment. But mostly, it is too expensive.
4:10:35
adlaistevenson
Are there still tradeoffs that make having more than one collector implementation desirable in a language?
4:11:15
beach
vtomole: What White_Flame says. The GC is not standalone. The entire system with its representation of objects etc depends on the GC technique, and vice versa.
4:12:48
White_Flame
adlaistevenson: but azul's (mostly) fully concurrent GC has a lot of good claims there
4:14:21
beach
vtomole: For example, if you want an incremental GC (which you need for real-time or soft-real-time systems), then the compiler must generate code to take into account that objects may move at (almost) any point in time.
4:18:30
White_Flame
come to think of it, symbolics genera let you allocate "regions" which had their own memory configuration. I don't recall if that meant you could have actually different GC strategies per region, or just tweak some preferences per region on the same GC strategy
4:18:33
adlaistevenson
Dijkstra's Tri-Color Garbage Collector looks fine because it has no pauses, that I remember. If pauses are avoided, it is good for real-time systems.
4:19:28
beach
adlaistevenson: We have come a long way since. But even that collector requires collaboration from the mutator for write barriers.
4:20:33
White_Flame
there's GC read/write barriers, assembly-level ordering barriers, and threading synchronization barriers, that at least spring to mind
4:20:43
beach
adlaistevenson: http://dl.acm.org/citation.cfm?id=1134023 is one example of recent techniques.
4:21:55
beach
adlaistevenson: More like "If you attempt to write a reference to a white object into an object that is black, then either revert the black object to gray, or color the write object gray.
4:22:16
beach
adlaistevenson: Because that collector has an invariant that no black object must refer directly to a white object.
4:23:34
adlaistevenson
One problem with GCs I've seen, at least Go's GC, is that if there is too much allocation activity in a short time, the program will run into OS-enforced limit and crash. Garbage collector waits too long :-(
4:24:26
beach
adlaistevenson: That sounds more like a buggy implementation than a problem with a particular GC algorithm.
4:25:00
White_Flame
if you allocate a lot before discarding references to what you allocated, that's a legit out of memory situation...
4:25:25
White_Flame
the one thing that I hate the most about GCs is that most require you to specify a heap size
4:30:03
adlaistevenson
I wonder how people deal with long (multi-minute) GC pauses in production. Do they force the GC at certain times and rotate through the servers, so other instances are guaranteed not to be GCing at same time?
4:31:38
White_Flame
most huge systems are combinations of databases and distributed application servers