freenode/#clasp - IRC Chatlog
Search
13:42:08
drmeister
It got pushed back to April 3 - we had a huge storm here two days ago - that shut everything down the next morning.
13:43:16
attila_lendvai
drmeister: well, first take a look at least at the commit messages to see if it aligns with what you have in mind
13:44:32
attila_lendvai
as we agreed cst, and anything large, should be merged into dev, then i forward port the wscript related changes to my branch, and then it can go into dev
13:45:10
attila_lendvai
becase it's probably easier for me to forward port than to Bike and you to merge
13:46:10
attila_lendvai
ACTION hopes that there won't be large whitespace noise kinda changes in the wscripts...
13:47:32
attila_lendvai
Bike: yep, mostly just the wscripts. i don't know how much they are changed in cst. i remember seeing at least one change that will need to be addressed
13:48:15
Bike
well the long and short of it is cst won't be merged into dev for a while. it only builds with major slowdown.
13:48:33
Bike
i didn't think this would be important for your refactor, since your refactor isn't about lisp code at all- but i guess i missed a conversation
13:59:49
drmeister
attila_lendvai: Yeah - cst isn't quite ready - there were changes to the compiler that slow everything down. Bike is making changes to correct that but it's going to take some time.
14:00:56
drmeister
So right now we have dev and cst which differ primarily in Common Lisp code but there are differences in the top level wscript file - specifically where the submodules are pulled from for sicl and cst pulls Eclector
14:01:41
drmeister
So with that in mind - how do you recommend we proceed? Should we wait until cst has been merged into dev?
14:09:54
attila_lendvai
Bike: i don't think there's any big obstacles. i just wrongly thought that the cst is about ready for merge. if it's not going to happen in the next few days, then i suggest merging my PR. it's not that it makes fundamental changes to the build process that requires reading docs and refactoring the cst branch, so...
14:11:51
attila_lendvai
afterwards i can also merge and test the wscript related changes from dev to cst and push it, so that the final cst -> dev merge will not have wscript related conflicts
14:12:52
attila_lendvai
it changes some things, but nothing fundamental. the build_fboehm kinda interface is the same both on the cmd line and inside the wscript
14:14:08
attila_lendvai
it's mostly this: relocate all/most of the build-time code into tools-for-build/, which includes the file lists that were deep down in some wscript files. and it cleans up the wscript file without fundamentally changing it.
14:14:43
attila_lendvai
ACTION goes to see how cst is rebased/merged with dev to keep it up-to-date, if at all
14:16:37
attila_lendvai
so, it seems like dev is merged into cst every once in a while. maybe a fresh merge could be done if it's appropriate, then merging my build-refactor, then i merge dev again into cst, test it and push it if it builds fine.
14:17:37
drmeister
attila_lendvai: I've also been working with travis and have currently given up on it - here's the skinny.
14:18:16
drmeister
(2) I discovered from the travis people that the subscription would only build private repositories.
14:19:04
drmeister
(3) I had my 1 year subscription to travis-ci refunded and they increased the build time clasp-developers/clasp was allowed to 180 minutes.
14:19:37
drmeister
(4) Clasp does not build on travis in 180 min partly because they only provide one process/build.
14:20:52
attila_lendvai
drmeister: well, it's a pity that you wasted the time, but it's not too bad either. 3 hours will be enough eventually, so we can use it as a goalpost to drive the speedup efforts... :)
14:20:53
drmeister
(5) I looked into using AWS CodeBuilder but the pricing is crazy. https://aws.amazon.com/codebuild/pricing/
14:22:43
attila_lendvai
drmeister: if i can do that hypothetical stage separation for the bootstrap in a way that really separates stage-1 and stage-2 so that there's little crosstalk, then we could create a docker image with stage-1 (or 2?) already built, and the CI only running the build of stage-3
14:25:32
drmeister
Is there a way to get travis to launch a build using an AWS spot instance - that would be ideal.
14:27:50
drmeister
I think I can set up AWS access management to create a build task - I'm not sure how to wire everything together.
14:29:03
drmeister
The .travis.yml file doesn't indicate any way to launch a build on a non-travis server.
14:37:24
drmeister
Maybe the way to do it is to run Jenkins on a tiny, free AWS machine and have it launch builds using the AWS command line interface tools.
16:49:49
beach
Maybe they have changed things since last time I looked, but the Scheme syntax used to be defined in terms of sequences of characters, and not in terms of internal data structures, so that (a . (b)) is different from (a b).
16:51:52
Bike
anyway, a bunch of "read four bytes, then read eight or four bytes depending" code is probably going to look similar regardless, i figure
18:39:17
Bike
there's also a StructureClassCreator, but as i know structure instances are identical to instances
20:25:30
drmeister
It's Turing complete - from what I read it's a broad attack surface that hardly anyone is aware of.