libera/#shirakumo - IRC Chatlog
Search
14:14:22
Colleen
<shinmera> It fuses the history into the main repo, making it easier to keep local patches and push them back upstream.
14:18:43
Colleen
<shinmera> you should be able to do something like git subtree pull --prefix sbcl sbcl master
14:22:51
Colleen
<shinmera> yes, you should be able to do something like --allow-unrelated-histories
14:24:39
Colleen
<shinmera> according to some other stackoverflows you might need to add --squash to the command instead
14:27:10
karlosz
though this might not be the best way to go about it - i can resolve the merge conflicts but that doesn't update the copied runtime files
14:29:16
karlosz
yeah, hence why i was debating to do all the upstream relevant stuff first to avoid merging like this, but we'll see how broken things are after this merge
14:58:35
karlosz
although im worried we'll lose the overview on the nx specific stuff that was added
15:00:01
karlosz
yeah though the full diff is easier to parse when everything is rebased on top of upstream
15:00:30
Colleen
<shinmera> I suppose you could revert the merge commit and use git subtree pull with rebase instead?
15:09:19
Colleen
<shinmera> I tried patching a dll to make multiple sessions work, but apparently my dll version is too new or something
15:30:48
Colleen
<shinmera> https://stackoverflow.com/questions/12858199/how-to-rebase-after-git-subtree-add
15:32:08
Colleen
<shinmera> worst case you could make a new branch from the initial squash merge, merge upstream, then rebase master onto that?
15:33:20
karlosz
C:\msys64\home\karlosz\trial-nx\sbcl\src\runtime/wrap.c:113: undefined reference to `realpath'
15:37:05
Colleen
<shinmera> if it fails with the runontarget step, you'll need the nintendotargetmanager and connect to it there
15:37:29
karlosz
[Error] Invalid format .adf file. At least one file must be included in the data region.
15:45:11
Colleen
<shinmera> ah, looks like you just need to create a random file in the data/ directory.
18:28:28
karlosz
yeah i don't know if i ever tried visual studio with sbcl, have to figure that out too i guess
18:30:48
karlosz
just being able to see the assembly itself and the address of the program counter is already a lot of information ;)
18:35:47
karlosz
shinmera: ok so here's another logistical question: we can't run the arm64 linux build on the windows vm
18:36:24
karlosz
so we need to run the buiukld and shrinkwrapping procedure on an arm64 linux vm and then transport those artifacts to the windows vm for it to finish linking the sbcl runtime with the .s and .o file
18:38:11
Colleen
<shinmera> For now, anyway. I'll have a proper think about a better build process that requires less *waves hands* at some later date.
18:39:34
karlosz
i remember when i was doing stuff for playstation they had some server/client script that allowed you to run everythingon linux
18:40:25
Colleen
<shinmera> and yeah, that's also an option, but ime running an sshd on windows is a pain.
18:40:55
karlosz
i don't know your internal network layout but just connecting those two is all i really need for the near future
18:45:05
karlosz
gonna try to get a shrinkwrapped thing on linun and transport the .s file over and try linking
18:46:42
karlosz
ehhhh i'll do that later. going to fix dinner, feel free to kill the workstation whenver, i probably won't get anything useful done anymore today
19:48:45
fullmera
Hello! I have been having a small issue with Trial where *context* is nil while a shader class change event is being handled, which leads to an error with ALLOCATE. Under what conditions should *context* be nil during a render loop's update?
19:51:04
Colleen
<shinmera> *context* can only be NIL: 1. prior to launch-with-context, 2. after launch-with-context exits 3. in a new thread
19:51:28
fullmera
I made a method on update :before main to break if *context* is null, and it seems to be true for a number of updates after launch porportional to the target frame time
19:55:39
fullmera
It seems like a busy time, so I don't want to impose too much. It is likely that I'm making an obvious mistake of some kind. I'll let you know if I produce a reasonable error report as I continue debugging
19:57:43
fullmera
Alright. I could upload my code to github; it is close to a minimal case for drawing a vertex entity on screen. I'm just trying to get things together for the new lisp game jam
20:12:49
fullmera
Thanks. The workbench is fine, and so is Kandria from source. I was trying different things to alleviate the error, and the before I was aware of the target frame time association I had been messing around with render passes. The behavior seems the same with just a render pass entered
20:40:54
fullmera
I can reproduce the issue with the workbench by setting WORKBENCH's :default-framerate initarg to 99 (putting the target frame time just above the delta-time). If an update happens before a render then *context* will be nil
20:59:11
Colleen
<shinmera> Can't fetch the error message either, that in itself gives a bogus value.
21:06:25
Colleen
<shinmera> I'm now just rambling, but this kinda dumb shit is why I wince about the Lisp community being so splintered
21:17:36
fullmera
Nice work, and thanks for the fix! Funny kludge. Those opengl errors are hairy for sure.
22:50:59
Colleen
<|3b|> shinmera: https://github.com/Shirakumo/trial/blob/standard-renderer/shader-pass.lisp#L170 typo inptus ?