freenode/lisp - IRC Chatlog
Search
20:55:35
fortitude
burtons: on my sbcl it does the right thing; did you maybe forget to use a package specifier for VAR?
20:56:18
fortitude
burtons: e.g. (ps:ps (ps:var foo)) ;=> "var foo;", but (ps:ps (var foo)) ;=> "var(foo);"
21:51:15
fortitude
burtons: the parenscript code defines printers using EQL-specialized methods, so it's not by symbol name
21:51:28
fortitude
burtons: I'm betting if you evaluate (symbol-package 'var) in both environments, you'll get different results
22:01:32
burtons
I'm in CL-USER for both of them. There's nothing using packages in the code that should be different between environments.
22:11:05
burtons
I'm blindly hitting 0 in slime like I was in lispworks and it's uninterning the symbols from parenscript.
22:13:47
burtons
Depending on if I eval and then compile, I get restarts on redefined symbols, although none are being defined in my own program. Mostly I see 'false' being redefined.
22:14:20
burtons
I don't like it but it's been working and I just put it up to one of those things I'll figure out later.
22:16:48
Bike
okay, so it sounds lke something strange is happening with symbols. is this program in a package you define? what packages do you use? paste, maybe?
22:18:12
burtons
I am loading parenscript using quicklisp. Open my single file, run slime-eval-buffer and get: Using package PARENSCRIPT results in a name conflict for this symbol: FALSE.
22:20:47
Bike
because i can see from lispworks's documentation that it exports the symbol 'false' from the 'lispworks' package, which is probably used by cl-user.
22:21:36
Bike
try having, like, (defpackage #:my-program (:use #:cl #:ps)) (in-package #:my-program) at the top of your file, remove the use-package, and see if it goes away.
22:24:20
burtons
But calling slime-compile-and-load-file doesn't execute them. I've tried wrapping them in an eval-when (:compile-toplevel) but it doesn't seem to do what I expect, which is load them so I can compile successfully. This has lead me to eval the buffer first before compiling.
22:32:35
burtons
Nope, parenscript still isn't working for me after using the defpackage as suggested.
22:33:37
burtons
I've had it working before when I wrote sigil, a command line compiler for it, but now I'm working with it from the lisp image and it's a bit of a pain.
22:35:30
burtons
It's my lack of CL knowledge I'm sure, but it's beyond me right now to be able to fix it.
22:48:59
burtons
Basically, it looks like I have to prefix all of the parenscript keywords with a package specifier if I want to use it with sbcl.
23:06:28
burtons
Here's one: https://itunes.apple.com/ca/app/typing-english-edition/id1205351354?mt=12
23:07:00
burtons
Heres' the other: https://itunes.apple.com/ca/app/typing-common-lisp-edition/id1202707132?mt=12
23:07:28
burtons
Took a day to figure out everything to get it signed properly for submission but now I've got a script to handle most of it.
0:04:29
Xach
drmeister: you could look into what quicklisp does (it's in quicklisp.lisp and ~/quicklisp/quicklisp/http.lisp) or look at what Clozure CL does
0:04:37
drmeister
I'm searching but nothing seems to work - maybe because I'm connecting through my phone and the connection is iffy.
0:10:51
Xach
I have a hard time getting interested in "X for Y programmers" tutorials - the order in which you learn programming languages is very much a coincidence, and I think it can slow down learning if you treat later ones in terms of earlier ones too much.
0:12:46
Xach
I think you will learn Lisp fairly easily from good Lisp tutorials, like Practical Common Lisp and Paradigms of AI Programming, without a fast-track for previous ML knowledge.
0:13:16
failproofshark
practical common lisp assumes you know how to program, which is actually abetter recommendation
0:55:11
drmeister
I'm looking at trivial-http and it uses usocket - which supports ecl (of course) but via the ecl specific features that I didn't support.
0:56:53
Xach
quicklisp uses sb-bsd-sockets on sbcl, or whatever else whatever else implementation provides.
0:57:09
Xach
if you can open a connection, write octets, and read octets, quicklisp can work with it.
0:58:16
fortitude
drmeister: worked pretty well after I fixed a small bug (not sure if it's quicklisp, though)
1:07:33
Xach
drmeister: feel free to rip off the quicklisp stuff. change the package name and such and you should be relatively good to go.
1:08:38
fiddlerwoaroof
if you don't mind an extra C dependency, there's also carrier by orthecreedence
2:19:41
Oladon
I have a project that was working a year ago, from which I took a hiatus... and now it doesn't work anymore. And the library in question was last updated in 2014.
3:06:30
krwq
i got possibly stupid question: how do you step through the code? when i put (break) in the first line of my function and click "s" in slime it immediately leaves the function
3:30:09
Oladon
Xach: The web scraping code was mis-parsing a document. I suspected the document had changed, but in actuality it turned out that I had made a mistake when I picked the code back up this year.
4:39:43
aeth
Oh, I see how SBCL stores Unicode strings in its fasls. ^@^@^@f^@^@^@o^@^@^@o^@^@^@ ^@^@^@b^@^@^@a^@^@^@r for "foo bar" so either padded UTF-8 to be constantly 32-bit or UTF-32 or both (not sure if there's a difference, and if there is if there's a way to tell)
4:40:41
BusFactor1
And I'm playing with this idea called 'typers', variables that can be values or functions depending upon their context.
4:41:59
BusFactor1
But generally they'll be functions in the end...they're meant to be passed to the sinusoid generators as paramters to create a synthesizer.
4:45:16
aeth
All I know is that I can replace the three null characters with "" in emacs and then read a lot of literal strings. (obviously saving would break the fasl file)
4:48:27
aeth
interestingly, the CCL fasls seem to use UTF-8 or ASCII because I can see those in emacs directly
5:02:12
aeth
Most *major* Lisp projects have a bus factor of 1 or 2, even if they get occasional patches from others.
5:02:55
BusFactor1
I think that's where the integration problems come from. But that coherency will come with time.
5:07:12
BusFactor1
This is actually my company name. And it's lisp based, but not ready to take on employees.
5:08:19
vtomole
Hey, i'm having problems running the example in this README: https://github.com/tanakahx/cl-binary, my with-open-file for stream works fine, but this get's me an "out" not defined. Any help is appreciated!
5:11:55
beach
vtomole: And what is the relation between the with-open-file you talk about and the with-open-binary-file in the example?
5:13:13
vtomole
Oh jesus, you are right, wrong package, thought it would work in cl-user, I should sent a fix to that readme but it looks like the project is dead.
5:18:11
beach
vtomole: I think it assumed that the user known that the library won't try to magically import its symbols to the cl-user package.
5:19:14
beach
vtomole: Having said that, I should add that I know prefer to use explicit package prefixes for external libraries, and for such usage, it would be good to supply the package prefix in the examples.
5:49:10
beach
Yeah, but this practice is unfortunately incompatible with the convention of using long package names, like pjb does for instance. Package aliases would come in handy, but we don't have them yet.
5:49:54
axion
But yeah, it goes a very long way towards making your code understandable, amoung other benefits.
5:50:12
beach
Not in my world. :) I always pretend I am in a LispOS where all software is present at the same time.
5:51:52
beach
Right. In trying to clean up the code for (first) Climacs, I couldn't even figure out where most operators were defined, because it :USEd all its external packages.
5:52:24
beach
It is amazing how reading one's own code from a few years back gives quite a few surprises.
5:52:40
axion
The only thing I use now, is alexandria, because I use a handful of functions in every project, and it has almost become part of the standard for me. I really should be just using :import-from though
5:56:27
axion
What is more annoying are the surprises from reading other peoples code with many USE'd packages. I bet these developers either have a hard time naming symbols, or take the Emacs approach that lacks multiple namespaces.
6:04:25
beach
This discussion reminds me that I should probably ditch my attempt to clean up the code of (first) Climacs, and start over. My current attempt became to error prone and I fear that I will never get it to work again this way.
6:40:11
beach
1. Make sufficient progress on Second Climacs so that it can display Common Lisp code from the parse results of the incremental parser.
6:40:17
beach
2. Create a special analyzer that will highlight imported symbols without a package prefix (other than symbols from the Common Lisp package), and provide a tooltip that will show the name of the package of the symbol.
6:40:28
beach
5. Import selected parts of the cleaned up code from (first) Climacs to Second Climacs in order to make faster progress on Second Climacs.