freenode/#lisp - IRC Chatlog
Search
0:58:33
Xach
vms14: there's a project already that defines all tags in a package nanmed "<" and it is funny to read
1:01:32
fiddlerwoaroof_
Anyways, I just discovered that the #p macro has a high chance of ruining your day.
1:03:03
fiddlerwoaroof_
I built a little GUI app in Lispworks for some AWS stuff and when I shared it with my coworkers, it didn’t work for them. This lead me to discover that it’s evaluated to a pathname object at read tome
1:03:41
fiddlerwoaroof_
So that ~ is expanded to the home directory on the build machine and not the end-user’s home directory.
1:05:28
Xach
fiddlerwoaroof_: does it defer the attempt to home-ize it if you use a string to designate the pathname instead?
1:08:21
fiddlerwoaroof_
I didn’t try that, I just switched to merge-pathnames and user-homedir-pathname.
1:08:22
fiddlerwoaroof_
Anyways, if you use fukamachi’s aws library, my fork will have a fix for this in a couple minutes :)
1:14:16
aeth
vms14: I mean, sure, that looks like it works, but I personally would rather have a series of write-foos than "<~a~~{~~{~~^ ~~a=\"~~a\"~~}~~}>~~a</~a>"
1:14:42
no-defun-allowed
Something like (macrolet ((generator-list (&rest list) (cons 'progn (loop for name in list collect (list 'generator name))))) (generator-list p main section article))
1:14:45
aeth
vms14: Also keep in mind that when you're generating format strings you basically commit to writing a macro since it's much more efficient for FORMAT to know what its format strings are ahead of time because FORMAT can be very optimized
1:14:46
vms14
aeth: the only complaint I have with this format is I know there is no need to repeat arg arg
1:59:01
Josh_2
wouldn't it be better to just be able to go (ul (li "ree") (li "ree")) and have it all join up nice?
2:47:27
vms14
(defun make-text-buffer () (make-array 0 :adjustable t :fill-pointer t :element-type 'character))
5:20:08
beach
I was thinking, now that we have a portable reader (Eclector) would it be possible (and worthwhile) to also have a portable printer?
5:24:42
MichaelRaskin
I guess most of the print-object methods defined use the standard printer for the objects' components. So consistency (or coverage) might be rather hard to achieve
5:25:23
MichaelRaskin
Although I don't know if there are any inconsistencies in the standard printer across implementations
5:26:30
beach
Why does the fact that the "standard printer" is used make it hard to achieve consistency?
5:29:28
MichaelRaskin
OK, what should be achieved compared to the standart print-object generic function?
5:30:52
beach
Nothing. Just the possibility of a common library rather than a separate one for each Common Lisp implementation.
5:31:32
beach
I am always trying to cut down on the combined maintenance burden for free Common Lisp implementations.
5:34:59
beach
These things come up when I need some module for SICL that does not seem very implementation specific to me, but I also don't see an existing library.
5:36:58
beach
So, why does the fact that the "standard printer" is used make it hard to achieve consistency?
5:38:03
MichaelRaskin
I thought that the goals include implementation-independent output consistency when used as a user-level library
5:39:00
beach
OK. No, on the contrary, such a module should make it possible for each implementation to customize the output.
5:42:15
MichaelRaskin
I would also fear that efficient printing of floating-point numbers would end up target-platform-dependent
5:43:47
beach
I was thinking of incorporating the latest research on that topic into such a library.
6:35:00
beach
stylewarning: I was able to program the new version of Clouseau to inspect SICL bootstrapping objects in a readable way.
6:37:07
stylewarning
beach: what happened to music notation or whatever it was precisely that was of interest to you
6:38:13
beach
stylewarning: There has been progress with standardization. Version 2 of Gsharp (called Clovetree) is going to use this standard and a free music font.
6:39:17
beach
stylewarning: jackdaniel is working on the GUI for Clovetree, and I have vague plans for the model.