libera/#sicl - IRC Chatlog

22:46:39 Bike yeah that repl stuff is what i'm asking about

22:46:46 Bike that sounds like it could be an eclector version mismatch

22:47:30 Bike https://github.com/s-expressionists/Eclector/commit/c6c76ab4f57db9a812d107e21251b65ff69078d5 looks like *client* being in that package is a year old

22:51:37 pfd As mentioned earlier, I completely deleted my quicklisp folder and when I re-cloned SICL, a little earlier I simply ran Robert's get-depencies.sh file, which I hope pulls the latest version of the needed dependencies.

22:53:50 pfd Also, there are differences between the SBCL versions. This particulare Line15 double error only occurs with SBCL 2.2.4.  I got down to lines 41000 with 2.2.3, 2.2.2 and 2.1.9 . Those three version presented fatal 23 fatal errors,

22:54:52 pfd Mind you this was a cursory observation. If it helps Robert, I can do a meticulous and careful step by step account with each SBCL version, etc.

23:58:07 Bike did you nuke cached fasls? they can sometimes screw things up. should be in ~/.cache/common-lisp/

23:58:38 Bike i really think the sbcl version differences are spurious. nothing in sicl is depending on bleeding edge sbcl

23:59:05 Bike you can also do (ql:where-is-system :eclector) to make sure you're loading the right thing

23:59:13 Bike (and then you can look at that thing to make sure you have the right version)

0:21:37 pfd Why the heck does it depend on being in my ~/.cache/common-lisp/? Isn't QL smart enough to put it there on first invocation?

0:21:38 pfd Anyhow, I'll try ql:where-is-system :eclector, but I really don't think that's the problem. Let me check, one sec.

0:29:13 pfd :Bike My copy of Eclector is exactly where it's supposed to be; as placed there by Robert's script, in '~/quicklisp/local-projects/Eclector'.

0:30:42 pfd After dinner I'm going to nix SBCL 2.24 and downgrade to SBCL 2.2.2.  If I'm right there's something different about 2.2.4.

0:30:55 pfd Right now it's my turn to prepare dinner, etc....

1:24:10 Bike pfd: the _fasls_ go in .cache/common-lisp, not the source

1:24:53 Bike pfd: does the eclector downloaded by the script match the eclector on github? because the eclector on github definitely has *CLIENT* in ECLECTOR.BASE

1:31:50 pfd Yes, I understand that the fasls go into the .cache. So that's where the compiler should put them before the rest of the bootstrapping needs them.

1:31:51 pfd Robert's script shows that it's pulling Eclector from the correct github s-expressionts account.  So let me take a peek at this ECLECTOR.BASE file in my copy. One sec.

1:36:21 Bike that is where the compiler put them. what i am referring to is that sometimes, if you compile one version of a source, asdf will cache the fasls there. then it turns out you were using the wrong source, but the fasls are still there, so when you try to load the new source you get the old fasls.

1:37:22 pfd That's why I was clearing my .cache after every failed attempt. I was doing this methodically.

1:37:48 Bike oh ok. so yes, you did nuke cached fasls. that's all i was asking.

1:37:49 pfd Now is there supposed to be a client.lisp file in the folder /Eclector/code/base ?

1:38:02 pfd If so. You're right, it's not there.

1:38:08 Bike No

1:38:24 pfd I don't see a file anywhere called ECLECTOR.BASE

1:38:26 Bike https://github.com/s-expressionists/Eclector/tree/master/code/base this is what files should be there, and if you look at package.lisp, you should see an export of *client*

1:38:45 Bike eclector.base is the name of a subsystem, not a file

1:39:56 pfd OK Thanks. let me take a look at my package.lisp file.

1:40:24 Bike6 ** NICK Bike

1:41:30 pfd Shoud I paste the contents of the file here? Or what's that DPaste link?

1:41:51 pfd I can just just paste the lines with *CLIENT*

1:42:31 pfd Lines 39 to 41:

1:42:32 pfd   ;; Exported for eclector.reader, not public use.

1:42:32 pfd   (:export

1:42:33 pfd    #:*client*

1:43:07 pfd   ;; Exported for eclector.reader, not public use.

1:43:07 pfd   (:export

1:43:08 pfd    #:*client*

1:43:08 pfd    #:%reader-error

1:43:09 pfd    #:%recoverable-reader-error

1:43:09 pfd    #:recovery-description

1:43:10 pfd    #:recovery-description-using-language

1:43:10 pfd    #:format-recovery-report

1:43:11 pfd    #:read-char-or-error

1:43:11 pfd    #:read-char-or-recoverable-error))

1:43:13 Bike okay. so that's the right file, probably. and probably _not_ the file that was being loaded earlier when you saw that error referring to *client*.

1:43:30 Bike and yes, please use some kind of paste service for anything more than a line or so. any of them should do

1:43:46 pfd It was right there the last time I tried, with my cache emply!

1:44:24 Bike i don't know what to tell you. that package definition very obviously exports the symbol *CLIENT* from ECLECTOR.BASE. the error message said there was no such symbol in that package.

1:44:26 pfd So, give me some time to methodically experiment as per my suspicion.  I'll be open minded towards being completely wrong.

1:45:18 pfd So, let's continue this tomorrow unless you're available in 90 min or so.

1:45:39 pfd I can't do this carefully immediately.

1:45:53 Bike sure, no need to rush

1:46:27 pfd BTW what version of SBCL were you able to successfuly bootstrap this latest iteration of SICL.

1:46:29 pfd ?

1:46:50 pfd with?

1:46:54 Bike 2.2.2

1:47:46 pfd Thanks. I'll step back to that version, which I recall didn't hiccup at line 15! I'll also check SBCL 2.2.3.

3:00:17 beach Good morning everyone!

3:01:25 Bike  morning.

3:12:24 hayley Good morning beach!

4:00:52 pfd Good Morning Beach!

4:05:57 pfd :beach All my bootstrapping trouble disappeared, rendering a completely error-free process, for the first time, regardless of which SBCL version I'm using, once I cleared /usr/share/common-lisp .

4:05:58 pfd When I manually install a version of SBCL the installer doesn't put anything there. However, I suspect apt & Synaptic do.  I'm going to make a point of keep an eye on this folder, from now on; especially if I get strange errors! ;-)

4:06:33 beach I see. Congratulations to fixing everything!

4:09:51 pfd Unfortunately it took me all day to figure this out. But what actually brought that path to my attention was when I invoked SBCL 2.2.2 before deleting the QL .sbclrc file, and so I received instantaneous warnings regarding content in that folder!  I must've ignored these warnings earlier today, thinking it was just someting in the .sbclrc file.

4:10:48 beach Hmm. Yes, I see.

4:14:00 pfd I've played and installed all manner of common-lisp libs through Synaptic in the past. I guess that's what generated a few errors with bootstrapping SICL, previosly.  I was just 'Acceting' and thinking these hiccups were part of the process. Now, I realize how meticulous and quality oriented you are. That's the impression I get reading your

4:14:00 pfd documents. It's also why I'm motivated and impressed with your vision regarding fixing CLTL2, among other CL aspects.

4:14:46 beach Oh, thank you!

4:14:50 pfd So now I'm really excited about exploring SICL continuously!

4:14:57 beach Great!

4:16:34 pfd SICL, and, I'm also interesting in CLASP.  I managed to complete of build of CLASP yesterday with yitzi's help.

4:16:57 beach Good. They are very different animals though.

4:18:25 zak1 ** NICK z4kz

4:18:31 pfd Yes. I believe I quite understand the differences. Aesthetically, I prefer to do everything, all the way down to machine code/asm interfacing using CL, and not lean on C++

4:19:10 beach Clasp is constrained by the desire to interoperate with C++.

4:19:15 pfd But if CLASP really matures with impressive features, and it fills a need, I won't ignore it.

4:20:20 z4kz beach: what is the current state of the sicl project?

4:20:27 pfd Yes, I've already seen some examples of weird looking code that way, withiin a Lispy patterns.

4:21:38 beach z4kz: I am still working on bootstrapping, which is the essence of the SICL implementation. But there are already good libraries that resulted from the project, like Eclector, Cleavir, Trucler, etc.

4:22:26 pfd :z4kz If you get even one single error during Pt.1 or Pt.2 of the SICL bootstrap process, and you're on a Debian or Debian derivative system like Ubuntu or Devuan, clear your /usr/share/common-lisp folder!

4:22:45 beach z4kz: Nobody has attempted to bootstrap a Common Lisp system this way, so there is nothing to learn from, other than my own mistakes.

4:25:18 pfd But once you listen to a Robert Strandh presentation or, even better, make the time to 'make' his documents to PDFs and read the visionary motivation behind SICL, it's truly inspriing, especially if you have a big collection of CL books like I do!