freenode/lisp - IRC Chatlog
Search
14:28:21
beach
There is a lot of code factoring in there. It depends on McCLIM and a CLIM library called ESA (for Emacs-Style Application).
14:29:30
beach
And it is not written the way I would write it today. There is a lot of :USE going on, so it is hard to figure out where each symbol comes from, at least by just looking at the code.
14:31:12
beach
So the code in this repository: https://github.com/robert-strandh/Climacs does not work and does not reflect what you get in Quicklisp.
14:33:05
beach
And in https://github.com/robert-strandh/Climacs it is still first Climacs, except a failed attempt to clean it up.
14:33:59
beach
This repository: https://github.com/robert-strandh/Second-Climacs contains a very embryonic version of Second Climacs. It can't easily be installed and executed yet.
14:38:00
beach
An X11 resource is a 32-bit number, but it has a few bits guaranteed to be 0 so that it can be encoded as a Lisp fixnum.
14:40:45
beach
Now, (first) Climacs depends on McCLIM, and currently the CLX backend is the only one truly working for McCLIM, but there is work going on for a Windows backend, and also for a framebuffer backend that could be used with other display servers.
14:43:41
beach
You are in for some work. But we will help you out if you have questions. For stuff like that, you may have better luck in the #clim channel.
14:46:07
beach
The CLX backend for McCLIM can currently work in two different ways. The old way is that each CLIM sheet is mapped to an X11 windows. The new way is that only a top-level window is created, and McCLIM is managing its own nested sheets.
14:49:01
beach
It's the new way, because it is closer to what other display servers would offer, so the code that lets McCLIM control nested sheets needs to work well in order to enable us to created other backends.
14:52:20
beach
The code for CLX is currently maintained by sharplispers: https://github.com/sharplispers/clx
14:53:19
beach
... and this is the current repository for McCLIM: https://github.com/robert-strandh/McCLIM
14:54:56
beach
jackdaniel, who is currently maintaining McCLIM, has done a great job factoring the code, fixing bugs, merging improvements from others, and also fixing CLX problems when they were encountered.
15:20:11
varjag
just the other day i loaded som textbook examples from late 1980s into sbcl, and they worked without modifications
15:28:57
varjag
http://trove.nla.gov.au/work/18000379?q&sort=holdings+desc&_=1487950116513&versionId=39949380
17:51:08
drmeister
I'm making progress running Cando/Clasp in a docker container. But swank is closing the connection again and in slime I get this message:
17:51:19
drmeister
Error running 'timer `slime-process-available-input': (error "Selecting deleted buffer")
18:17:06
fortitude
does it seem like a bad idea to generate gensyms at runtime to use as task/thread IDs?
18:17:22
fortitude
it's not actually interning anything, but I don't think *GENSYM-COUNTER* is thread-safe
18:51:24
pjb
fortitude: just use (incf *next-thread-id*) Why would you need to allocate a new symbol?
18:54:31
fortitude
I assume for readability; I wrote this code quite some time ago, and can't recall exactly what I was thinking
18:55:03
fortitude
it's questionable whether I even need a task ID, since you could always just return the task object itself unless you were serializing (which I'm not)
19:17:00
pjb
fortitude: it's usually easier to remember and reference small numbers or strings, than object identities.
19:44:04
fortitude
is there a common convention for including/excluding multiple items with #+ and #-?
20:06:34
|3b|
ACTION notes that most keyword arguments aren't on *features* so you can just do #+:a 1 to get rid of :a and 1
20:26:55
burtons
(var ...) declerations are being rendered as var(..) function calls; this doesn't happen on LW.
20:31:34
drmeister
Has anyone used cl-jupyter recently and would have a few minutes to answer a few questions about it?
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