libera/#clasp - IRC Chatlog

17:15:02 yitzi Bike: I think the logical pathname are getting mangled in `llvm-sys:create-file` and the usage of `llvm::DIFile`. The logic there seems to assume physical paths with `/` separators.

17:18:32 Bike the logic in DIBuilder::createFile?

17:20:16 yitzi Meant the usage of createFile. Specifically make-file-metadata.

17:22:05 yitzi https://github.com/clasp-developers/clasp/blob/aba76e80d3074243241031829ac0dd5486ffd50d/src/lisp/kernel/cmp/debuginfo.lisp#L110-L123

17:22:07 Bike ahh, i see. good, that's a lot more fixable

17:23:09 yitzi I am making an attempt at it. Basically, not using the directory field at all and just shoving the whole namestring into the Filename

17:24:36 yitzi Found that while using STEP the returned pathnames for the frame stack was things like `/src/lisp/kernel/....` vs `sys:src;lisp;kernel;...`

17:26:11 Bike maybe we could check if the pathname is logical (i think (typep pathname 'logical-pathname)?) and choose a separator appropriately, if sticking everything in the file field doesn't work

17:27:03 yitzi Yes, that would make sense. The only obstacle might be if a physical pathname has a host or a device component?

17:27:05 Bike oh, or actual directory-namestring itself screws it up

17:27:20 Bike (directory-namestring #P"SYS:SRC;LLVMO;DEBUGINFOEXPOSE.CC") => "/SRC/LLVMO/"

17:27:35 yitzi Yeah....not good.

17:28:33 Bike maybe we can just change that. it looks like on sbcl directory-namestring on a logical pathname keeps the ; separators.

17:28:48 Bike (checking because pathnames are an area of the standard i'm less familiar with)

17:29:14 yitzi I am changing the corresponding `getPath` function so that it checks for an empty directory string. `(directory.empty()) ? filename : (directory + "/" + filename);`

17:30:15 yitzi Hopefully that will work if some other code creates `llvm::DIFile` and actually uses the directory slot.

17:30:55 yitzi Does SBCL keep the host is directory-namestring?

17:31:02 yitzi s/is/in/

17:31:02 Bike no.

17:31:45 yitzi That would make it difficult. We wouldn't know what logical host the DIFile is pointing to.

17:32:35 Bike maybe we could use enough-namestring instead of directory-namestring?

17:33:13 Bike except i guess that kind of works in the opposite direction

17:33:49 yitzi Well, maybe not using the Directory slot will work. Fingers crossed.

17:47:49 yitzi That seems to work, although something is still shoving a `/` in front.

18:08:32 kpoeck Hello

18:10:15 yitzi Hi kpoeck. If you are building from recent main you'll need to delete build, dependencies and src/lisp/kernel/contrib/ before you rerun koga. Just FYI.

18:11:40 kpoeck Thanks for the info. Strangely enough it seem to have worked without that.

18:11:57 kpoeck not sure if I should do a clean build

18:12:15 yitzi That would be a good idea.

18:13:24 kpoeck well than i will do a clean build, i am looking for trouble

18:13:38 kpoeck i am not looking for trouble

18:15:25 kpoeck other question. the asdf guys seem to use a quite dated clasp for their ci. Do we have an docker image that is regulary updated that we could provide them?

18:17:11 yitzi Yes. https://github.com/clasp-developers/clasp/pkgs/container/clasp

18:18:38 yitzi It builds once a week. Really, it just installs the nightly builds and quicklisp. https://github.com/clasp-developers/clasp/blob/main/docker/clasp/Dockerfile

18:19:53 kpoeck that should be fine

18:23:36 yitzi Let me know if they need other stuff installed or any requests at all. I can change it anytime.

18:29:53 kpoeck In asdf there is sometimes - e.g. with ecl - like (if (version<= "2.21" tag) ... Do we have a version number that can be used for that? My (lisp-implementation-version) returns now "cclasp-boehmprecise-1.0.0-307-g3cb638c40-cst", perhaps not so extremly helpfull

18:33:30 yitzi Isn't there a software-version? ....

18:33:31 kpoeck and -i can still meta-dot to something defined in lisp, but not to lisp-implementation-version .

18:34:16 kpoeck The entry in TAGS is LCC_RETURN wrapped_cl__lisp_implementation_version_ 14382,915337, is that kosher? Didn't Bike reported something similar?

18:35:31 yitzi I think so...not really sure though.

18:35:57 yitzi `(software-version)` => `"1.0.0-312-gaba76e80d-g85e94b2d"` for cando.

18:36:35 yitzi For clasp it should return something like `""1.0.0-312-gaba76e80d-g85e94b2d"`

18:56:25 kpoeck does the 312 mean something?

18:57:18 kpoeck the version_number comes from (version configuration) i assume, but where is that calculated?

18:57:42 yitzi The number of commits since the "1.0.0" tag. Its git describe.

18:59:45 yitzi Its coming from here: https://github.com/clasp-developers/clasp/blob/aba76e80d3074243241031829ac0dd5486ffd50d/src/koga/units.lisp#L271-L277

19:04:47 kpoeck ok, so run-program than probably works since "1.0.0-304-whatever"

19:05:57 yitzi Sounds correct. I think the uiop version number comparison will work with "1.0.0-304"

19:09:32 yitzi Bike: the leading slash is being added by LLVM. I have been able to get around it by setting the directory to "_" when I want to ignore it, then looking for pathnames that start with "_/". A bit of a kludge.

19:10:05 Bike hum. would have expected llvm to pass any string though...

19:10:28 yitzi Its on the return, when you try to access the source info.

19:11:25 yitzi There may be a better solution. I've found a few more issues to fix though. Once I am done maybe you can look at it as see if you see a better way.

19:12:17 Bike i will take a look, but unfortunately our use of debug information has never been something i understand deeply

19:12:23 Bike i've wanted to totally rewrite it for a while, really

19:13:14 yitzi Yeah, I saw some notes about redundant structures, etc.

19:14:21 kpoeck (UIOP/VERSION:VERSION< "1.0.0.304" "1.0.0.312") works

19:14:50 kpoeck not with the hyphon

19:18:10 yitzi Yes, looks like they only allow periods.

19:21:03 kpoeck so should we define something in clasp that returns 3 digit tag + numberofcommits separated by dot?

19:23:40 yitzi I don't know if I agree with uiop's version rules. That is not how the version tags work in packaging systems. Would `(substitute #\. #\- (software-version))` work?

19:29:57 kpoeck We probably need to get rid of the part starting with g and the commit hash

19:32:42 yitzi So then, yeah probably need a uiop specific version function.

19:32:59 kpoeck (let ((version-raw (substitute #\. #\- (software-version))))(UIOP/VERSION:parse-version (subseq version-raw 0 (1- (position #\g version-raw))))) -'> (1 0 0 312)

19:34:55 yitzi cool

19:35:34 yitzi the g may not be there, btw

19:36:20 yitzi In which case, there won't be a "-312"

19:40:13 yitzi kpoeck: I think this allows for "1.1.0" which would be the value right after a release. https://plaster.tymoon.eu/view/3257

19:42:42 kpoeck If we only change tags every 4 years that wont help too much

19:43:22 kpoeck when woudn't we have a g?

19:43:48 yitzi I would anticipate v1.1.0 shortly before llvm14. Very soon. We will need a fixed version to get into the debian/homebrew repos

19:44:00 kpoeck anyhow the version in your paste is better

19:44:30 kpoeck before llvm14? I assumed after

19:44:44 yitzi If the commit is directly on a tag then the version number will just be that tag, nothing else.

19:44:57 kpoeck ok

19:45:13 yitzi I am torn about before/after.

19:46:40 kpoeck Would be good to know if a version is based on llvm 14

19:47:04 kpoeck when would you do the next version after 1.1.0?

19:49:39 yitzi I guess when we are happy that the llvm 14 stuff works? I agree v1.1.0 = llvm14 makes more sense, but I have submitted the debian packages for inclusion in Debian/Ubuntu yet. I don't know if want llvm14 out of Debian testing first.

19:49:51 yitzi I haven't submitted

19:50:08 yitzi s/if want/if they want/

19:57:00 kpoeck perhaps 1.0.1 before llvm14?

19:59:08 yitzi Well, we have a lot of changes on main, and the debian packages don't work with v1.0.0 because koga is in v1.1.0, so a patch release isn't gonna help.

19:59:49 kpoeck do llvm14 with 1.2.0?

20:03:33 yitzi Yes, that is a solution. Like I said, I am kind of indecisive. Does Debian usually do about a yearly release>

20:03:34 yitzi ?

20:04:30 yitzi No, two years.

20:04:48 kpoeck I believe you know much more about version numbers than i do :-)

20:05:54 yitzi Well, that makes it silly to wait for them. So I think your first suggestion was correct. v1.1.0 = llvm14 when llvm14 is available on homebrew and Arch (they are the holdouts)

20:06:41 kpoeck sounds good to me, Bike ?

20:07:38 yitzi My completely uniformed crystal ball says that llvm14 on arch/homebrew is about a month away. ;-)

21:07:23 drmeister I'm fine with v1.1.0 = llvm14

21:54:45 drmeister yitzi: Is there an option to force building scando?

21:54:53 drmeister I'd like to rebuild all of the quicklisp code.

21:55:15 drmeister Or where is the quicklisp cache?

21:55:58 drmeister `rm -rf build/boehmprecise/fasl/clasp-cclasp-boehmprecise-1.0.0-307-g3cb638c40-g9c97d8da-cst-macosx-x64/*`

21:56:33 drmeister I'll use `rm -rf build/boehmprecise/fasl/clasp-*`

21:56:51 drmeister No - that doesn't trigger the build.

22:08:27 yitzi drmeister: delete the scando binary

22:09:03 drmeister How about to force rebuild of eclasp?

22:10:06 drmeister When I'm working on eclasp common lisp code I should run cando

22:14:20 drmeister I changed the function CHEM::BONDED-ATOMS-AS-LIST in the C++ code to CHEM:ATOM/BONDED-ATOMS-AS-LIST. Then I changed all the Common Lisp source code to refer to CHEM:ATOM/BONDED-ATOMS-AS-LIST.

22:14:43 drmeister Now I'm trying to figure out what I need to do to rebuild the code so that I don't get the error:

22:14:55 drmeister UNDEFINED-FUNCTION: The function CHEM::BONDED-ATOMS-AS-LIST is undefined.

22:15:03 drmeister This is a common problem I have.

22:15:23 drmeister It's one of the "difficult problems of computer science" - cache coherance.

23:07:44 yitzi drmeister: delete the eclasp stuff in build/boehmprecise/fasl

1:27:38 drmeister This is from slyrus' hacked smiles parser:

1:27:40 drmeister https://usercontent.irccloud-cdn.com/file/MOzaFWZA/image.png