<< 03-11-2014 >>
00:00:58*Matthias247 quit (Read error: Connection reset by peer)
00:00:58VarriountOk, issue created and assigned to me - https://github.com/Araq/Nimrod/issues/1622
00:01:22VarriountRight now my priority is getting the builder up and running though.
00:04:01VarriountAraq: Just to confirm, you want the installers to use the Nimrod source code in the 0.9.6 release on the Github repo, right?
00:04:51Araqright
00:05:38*boydgreenfield joined #nimrod
00:07:58VarriountAraq: https://drive.google.com/file/d/0B077nrrf63xtYzZ4Q1puRnVJNE0/view?usp=sharing
00:11:59AraqVarriount: tested my patch ?
00:12:35Mat3ciao
00:12:48*Mat3 quit (Quit: Verlassend)
00:14:13Araqwell I uploaded it
00:14:24gokr1Araq: 50 million calls, I have like 5 different silly calls. Worked fine. :)
00:14:54Araqwell but you're lucky since you're on linux
00:15:07Araqfor windows it should be fine too
00:15:24gokr1I will try on OSX tomorrow.
00:15:29Araqbut for macosx the thread local storage emulation might cause problems ...
00:15:44gokr1gnite folks
00:15:56Araqbye
00:17:43*gokr_ quit (Quit: IRC for Sailfish 0.8)
00:29:24Araqping will
00:29:41willAraq: you called?
00:30:40Araqif build.nim-lang vs build.nimrod-lang is the issue how come it works with chrome but not with firefox?
00:30:55Araqwell ok, maybe it works with neither properly
00:31:03Araqbut only FF shows the error message
00:31:20willaren't you looking at the wrong page?
00:31:40willhttp://build.nimrod-lang.org/docs/lib.html
00:31:56flaviuAraq: Firefox is like linux. It's completely firefox's fault :)
00:32:45willyou are probably looking at: http://nimrod-lang.org/lib.html? which seesm to work in both firefox and chromium ;D
00:32:55flaviuFirefox has lots of open source extensions. Chrome has more proprietary extensions. Coincidence? I think not.
00:33:45Araqhrm wtf, let's see
00:35:02Araqwell, now it works on FF too. browser cache thing...
00:35:15Araqhowever it didn't work before
00:35:28Araqmaybe dom96 already fixed it
00:35:32willdoes http://build.nimrod-lang.org/docs/lib.html work though?
00:35:48rpagfor me yup
00:35:54willthat is compiled with 0.10.0
00:36:19Araqnope, but build.nimrod-lang is a second class citizen
00:37:32willwell the problem with that one is: http://build.nim-lang.org/packages?callback=gotPackageList in docs/lib.txt
00:37:54Araqwhich is correct for bigbreak
00:38:04willbut the link doesn't work
00:38:06will404?
00:38:07Araqit's just that it's still in flux
00:38:16Araqthe link will work
00:39:11willfair enough :D
00:39:28willit was gradha that compalined wasn't it?
00:39:36willcan't find the post on the forum
00:40:19Araqit was in the more general "we suck" thread
00:41:00Araqhttp://forum.nim-lang.org/t/600
00:41:03*q66 quit (Quit: Leaving)
00:42:55willoh yeah, I guess all is well then :D
00:43:24Araqyeah. btw
00:43:34Araqif one of you guys is looking for work
00:43:50Araqthe JS tagged bugs are usually easy to fix for newcomers
00:43:56*xenagi joined #nimrod
00:44:01Araqhi xenagi
00:45:22willcheers, I might try and fix a few when I get some more time
00:46:04xenagihi Araq
00:46:35Araqxenagi: please fix some JS tagged bug before you leave ;-)
00:47:06xenagiO_o
00:47:10xenagithis is news to me lol
00:49:23Araqwell one way out of this dilemma is to never leave again
00:49:56xenagiyes, there's that...
00:52:38*darkf joined #nimrod
00:53:20NimBotAraq/Nimrod bigbreak 771e3db Flaviu Tamas [+0 ±1 -0]: Remove extra trailing zero from oid... 3 more lines
00:53:20NimBotAraq/Nimrod bigbreak 65c64fd Andreas Rumpf [+0 ±1 -0]: Merge pull request #1621 from flaviut/fix-oid... 2 more lines
00:56:45NimBotAraq/Nimrod devel aa1fb9a Grzegorz Adam Hankiewicz [+0 ±1 -0]: Adds stringification support for nnkPostfix nodes.
00:56:45NimBotAraq/Nimrod devel e7edd9e Andreas Rumpf [+0 ±1 -0]: Merge pull request #1565 from gradha/pr_supports_nnkPostfix_stringification... 2 more lines
00:58:51NimBotAraq/Nimrod devel 2476ee0 def [+0 ±1 -0]: Add -lm for fesetround and fegetround
00:58:51NimBotAraq/Nimrod devel c0422ae def [+0 ±2 -0]: Move floating point rounding and exceptions handling to math... 1 more lines
00:58:51NimBotAraq/Nimrod devel a019825 def [+1 ±1 -0]: Move fenv to its own module
00:58:51NimBotAraq/Nimrod devel a0ecfd1 Andreas Rumpf [+1 ±2 -0]: Merge pull request #1448 from def-/posix-math... 2 more lines
00:59:08*bjz joined #nimrod
01:02:00AraqVarriount: just remembered ... I really like your idea of keeping separate output buffers for parallel exec
01:02:21NimBotAraq/Nimrod bigbreak 679aefd Erwan Ameil [+0 ±2 -0]: Prettify compiler output for verbosity=1... 2 more lines
01:02:21NimBotAraq/Nimrod bigbreak 06c32aa Erwan Ameil [+0 ±2 -0]: Tidy up the prettification of the default verbosity c compilation output
01:02:21NimBotAraq/Nimrod bigbreak 2f3add9 Erwan Ameil [+0 ±1 -0]: Change empty callback into nil
01:02:21NimBotAraq/Nimrod bigbreak 49e9332 Erwan Ameil [+0 ±1 -0]: Use defaut nil callback for execProcesses
01:02:21NimBot2 more commits.
01:03:30NimBotAraq/Nimrod devel 400fd6a Grzegorz Adam Hankiewicz [+0 ±1 -0]: Documents json module.
01:03:30NimBotAraq/Nimrod devel 57dadb3 Grzegorz Adam Hankiewicz [+0 ±1 -0]: Hides TJsonError, it wasn't being used.
01:03:30NimBotAraq/Nimrod devel db228d3 Andreas Rumpf [+0 ±1 -0]: Merge pull request #1553 from gradha/pr_json_module_improvements... 2 more lines
01:09:22NimBotAraq/Nimrod devel 9f99dd0 def [+0 ±1 -0]: Add list comprehensions to future module
01:09:22NimBotAraq/Nimrod devel c7898a0 def [+0 ±1 -0]: Extend list comprehension documentation
01:09:22NimBotAraq/Nimrod devel bd2ba2d Andreas Rumpf [+0 ±1 -0]: Merge pull request #1443 from def-/future-listcomprehensions... 2 more lines
01:10:46AraqVarriount: one more thing you could do: ensure that a release includes Nimble. just patch koch.nim to do that.
01:18:16*rpag quit (Quit: Leaving)
01:23:26*will quit (Ping timeout: 256 seconds)
01:26:51*brson joined #nimrod
01:41:32flaviuAraq: wrt gradha's PR, it's easy to apply it anyway. `git checkout devel; git branch gradhapr; git checkout gradhapr; git apply`
01:41:32flaviupaste the contents of https://github.com/Araq/Nimrod/pull/1383.patch and press ctrl-d;
01:41:32flaviu`git rebase bigbreak; git checkout bigbreak; git merge gradhapr`
01:52:52*flaviu quit (Ping timeout: 240 seconds)
01:55:58*xenagi quit (Read error: Connection reset by peer)
02:16:01*brson quit (Quit: leaving)
02:18:23*johnsoft quit (Ping timeout: 240 seconds)
02:18:29*johnsoft joined #nimrod
02:21:40*phI||Ip quit (Ping timeout: 258 seconds)
02:23:04*phI||Ip joined #nimrod
03:02:31*superfunc joined #nimrod
03:04:54*ehaliewicz joined #nimrod
03:11:18superfunchmp, that's odd. Git wouldn't see the bigbreak branch for csources after cloning and trying to checkout, but if I clone with --b bigbreak it had no troubles
03:15:46*bjz quit (Ping timeout: 244 seconds)
03:19:57*boydgreenfield quit (Quit: boydgreenfield)
03:20:19*flaviu joined #nimrod
03:20:55*superfunc quit (Ping timeout: 246 seconds)
03:21:57*flaviu quit (Remote host closed the connection)
03:24:16*flaviu joined #nimrod
03:41:52*bjz joined #nimrod
03:54:00*flaviu quit (Ping timeout: 244 seconds)
03:59:36*johnsoft quit (Ping timeout: 250 seconds)
03:59:45*johnsoft joined #nimrod
04:07:29VarriountAraq: Shouldn't Nimble/Babel be another component?
04:20:24VarriountAraq: Also, it might be more expediant to tell me how to upload the installers myself - that way I don't have to bother you each time they need to be updated/fixed.
04:21:38*Jesin quit (Ping timeout: 255 seconds)
04:46:50*johnsoft quit (Ping timeout: 265 seconds)
04:47:54*johnsoft joined #nimrod
05:10:04*Jesin joined #nimrod
05:29:16VarriountAraq: Eh, are the installers supposed to include babel?
05:37:44*ARCADIVS joined #nimrod
05:54:43*boydgreenfield joined #nimrod
06:35:54*boydgreenfield quit (Quit: boydgreenfield)
06:48:41*superfunc joined #nimrod
07:04:35*BitPuffin quit (Ping timeout: 265 seconds)
07:07:07*superfunc quit (Quit: Page closed)
07:12:02NimBotAraq/Nimrod bigbreak 1b4dd6f Varriount [+0 ±1 -0]: Update buildbat.tmpl... 2 more lines
07:17:39NimBotAraq/Nimrod devel 6935171 Varriount [+0 ±1 -0]: Fix math.nim on windows
07:34:44*gokr_ joined #nimrod
07:41:04*gokr_ quit (Ping timeout: 245 seconds)
07:46:19AraqVarriount: yeah, that's what I meant. the installers should include Nimble.
08:19:10*Pisuke quit (Ping timeout: 255 seconds)
08:21:36*Trustable joined #nimrod
08:29:00*mbenadda_ joined #nimrod
08:38:41*mbenadda_ quit (Quit: Lingo: www.lingoirc.com)
08:38:48*mbenadda_ joined #nimrod
08:41:35*mbenadda_ quit (Client Quit)
08:41:53*mbenadda_ joined #nimrod
08:51:54*khmm joined #nimrod
09:03:40*gokr_ joined #nimrod
09:19:11*Lynx_ joined #nimrod
09:42:30*ehaliewicz quit (Ping timeout: 258 seconds)
09:45:56*ehaliewicz joined #nimrod
10:06:19*ehaliewicz quit (Ping timeout: 265 seconds)
10:22:19*BlaXpirit joined #nimrod
10:36:05*BlaXpirit-UA joined #nimrod
10:38:52*BlaXpirit quit (Ping timeout: 240 seconds)
11:22:28*vendethiel- quit (Ping timeout: 244 seconds)
11:23:27*vendethiel joined #nimrod
11:36:40*flaviu joined #nimrod
11:36:59*q66[lap] quit (Read error: Connection reset by peer)
11:37:39*q66[lap] joined #nimrod
11:40:36*Boscop__ is now known as Boscop
11:56:02*flaviu quit (Ping timeout: 265 seconds)
11:57:28*flaviu joined #nimrod
12:03:15gokr1http://goran.krampe.se/2014/11/03/squeak-to-nim
12:17:34*Pisuke joined #nimrod
12:26:46*BitPuffin joined #nimrod
12:36:15Araqgokr1: what do you do with the ffiConcat's string?
12:36:31gokr1Mmm, I wonder too :)
12:36:59gokr1You mean the char* returned to Squeak from Nim, right?
12:37:12gokr1Which... is a GCed Nim string.
12:37:42gokr1And I was under the impression that Squeak FFI copies it, but perhaps its not.
12:37:59gokr1(but... it must be, Squeak Strings are something completely different)
12:38:39gokr1But... I can try a variant that I have found several examples of in our image - using byte* instead, and then copy it "manually".
12:39:24gokr1If that solves it - then I suspect that the Squeak FFI does something fishy with the char* coming back from Nim.
12:39:59gokr1Nim copies the args to concat, right? Doesn't do anything with them?
12:40:17Araqyeah
12:40:25gokr1ok, will try
12:40:38Araqit's essnetial that the squeak vm doesn't do weird things with threads
12:40:49Araqyou know, what you're doing here is really fragile
12:41:04Araqyou return a cstring that aliases GC'ed memory
12:41:26Araqnow the GC supports that, in theory
12:41:48Araqbut it has to see that single reference on the stack that it scans somewhere
12:43:39Araqalso for windows (and it doesn't hurt for other OSes) you should use the 'cdecl' calling convention for everything that you 'exportc'
12:44:58gokr1right.
12:45:23gokr1So... better is if Squeak allocates memory, then asks Nim to "fill it in", right?
12:46:46gokr1Yeah, I see what you mean - not so good :)
12:48:32gokr1So I presume the best approach is if the caller allocates args and results, let Nim "fill in", then after the caller has converted that into Squeak objects - the caller can free.
12:49:08Araqdepends but yeah, sounds about right
12:49:22gokr1This pattern is seen in lots of the FFI code in our image.
12:56:28gokr1So does Nim create some separate thread?
13:00:18Araqno
13:01:34gokr1So I modified the code to use "byte*" and then use #fromCString to copy that out into a String object. Seems stable now.
13:02:26gokr1In Smalltalk "#Blabla" means the method/message called "Blabla", also known as a "selector".
13:02:32gokr1(whatever)
13:02:55Araqnice, but eventually I think we should look into it again to understand where the crash came from
13:08:14NimBotAraq/Nimrod bigbreak 9f99dd0 def [+0 ±1 -0]: Add list comprehensions to future module
13:08:14NimBotAraq/Nimrod bigbreak c7898a0 def [+0 ±1 -0]: Extend list comprehension documentation
13:08:14NimBotAraq/Nimrod bigbreak 2476ee0 def [+0 ±1 -0]: Add -lm for fesetround and fegetround
13:08:14NimBotAraq/Nimrod bigbreak c0422ae def [+0 ±2 -0]: Move floating point rounding and exceptions handling to math... 1 more lines
13:08:14NimBot31 more commits.
13:18:55NimBotAraq/Nimrod devel f3d7158 Simon Krauter [+0 ±1 -0]: Fix terminate() and add kill()
13:18:55NimBotAraq/Nimrod devel a7f5d55 Simon Krauter [+1 ±0 -0]: Added test case
13:18:55NimBotAraq/Nimrod devel 33ce5c2 Andreas Rumpf [+1 ±1 -0]: Merge pull request #1620 from trustable-code/PR6... 2 more lines
13:18:56gokr1Araq: Yeah.
13:33:22*will joined #nimrod
14:13:05*Pisuke quit (Ping timeout: 264 seconds)
14:13:38*Sembei joined #nimrod
14:22:44*darkf quit (Quit: Leaving)
14:31:25Trustable Araq: Maybe move the test case for terminate() from "stdlib" to "osproc".
14:33:36*BitPuffin quit (Ping timeout: 265 seconds)
14:36:01AraqTrustable: ok. btw that JS issue seems to be gone for reasons I don't understand
14:38:20*BitPuffin joined #nimrod
14:41:04*vendethiel quit (Ping timeout: 272 seconds)
14:42:20TrustableAraq: what do you think of a to do list in the wiki?
14:42:42Araqwe already use the issue tracker for that
14:42:48Araqwell Varriount does
14:42:57AraqI have my own todo.txt
14:43:07*vendethiel joined #nimrod
14:43:22Araqand dom96 has his own too
14:43:27Trustablemaybe add a milestone for 0.10.0
14:48:38Araqmeh, the milestones didn't work too well for 0.9.6
14:48:53*dom96_ quit (Ping timeout: 240 seconds)
14:49:04TrustableJust found out that an issue be a list tasks.
14:49:19TrustableStill open issues for 0.9.6: https://github.com/Araq/Nimrod/issues?q=is%3Aopen+is%3Aissue+milestone%3A0.9.6
14:50:13*dom96_ joined #nimrod
14:54:49*dom96_ quit (Ping timeout: 260 seconds)
14:58:42*askatasuna joined #nimrod
15:04:24*q66[lap] quit (Quit: Textual IRC Client: www.textualapp.com)
15:04:32*khmm quit (Ping timeout: 265 seconds)
15:08:46*saml joined #nimrod
15:10:17*khmm joined #nimrod
15:14:44fowlgokr1, you probably get a segfault because you're returning the bytes from a string
15:15:15fowlthat is, taking them from a garbage-collected object and passing them around like they're just a pointer
15:22:30*khmm quit (Ping timeout: 244 seconds)
15:23:14*saml quit (Quit: Leaving)
15:23:30*Jehan_ joined #nimrod
15:25:29*saml joined #nimrod
15:27:20AraqJehan_: why does your patch require 'strutils'?
15:27:36Araqyou added that import to cgmeth.nim
15:27:51Jehan_Araq: Umm … may be leftover debugging code.
15:28:11Araqok as I suspected
15:28:26Jehan_I thought I had reviewed the code for such imports, but it must have slipped through.
15:29:50*vendethiel quit (Ping timeout: 272 seconds)
15:29:55gokr1fowl: I don't.
15:30:07fowlyou do in concat()
15:30:23gokr1You mean Nim code?
15:30:40fowlyea
15:31:28gokr1So the thing is that the Squeak FFI is meant to convert the Smalltalk String to a C string.
15:31:32NimBotAraq/Nimrod devel 52a3acb Reimer Behrends [+0 ±1 -0]: Fix method recursion bug.... 2 more lines
15:31:32NimBotAraq/Nimrod devel 1fc8bab Reimer Behrends [+0 ±1 -0]: Reset location when creating a method dispatcher... 8 more lines
15:31:32NimBotAraq/Nimrod devel bce2d57 Reimer Behrends [+1 ±0 -0]: Added test case for recursive methods.
15:31:32NimBotAraq/Nimrod devel ce9a57f Reimer Behrends [+1 ±2 -0]: Fix dispatcher creation for method prototypes.... 6 more lines
15:31:32NimBot1 more commits.
15:33:50AraqVarriount: please assign a priority to every issue; I rarely look at the bugs without some filter
15:33:52fowlgokr1, look at the function foo(), you create a string and then return the char*s from under it
15:33:56fowlthat shouldn
15:34:02fowlshouldn't be allowed
15:34:28gokr1Thing is - on the Squeak side I copy what I get.
15:34:33Araqfowl: it's an edge case. usually it works
15:34:58fowlgokr1, you probably get a crash when the GC runs between the time you send the string to squeak and get it copied
15:35:06Araqas long as the returned cstring is referenced from the stack until it's copied over
15:35:34gokr1So the GC would run before Squeak gets it back?
15:35:40gokr1Nim GC that is.
15:35:52*vendethiel joined #nimrod
15:35:54fowlit could run at any time
15:36:10gokr1Well, its not in a separate thread, right?
15:36:17Araqright.
15:36:25Araqdon't listen to fowl ;-)
15:36:29Jehan_Araq: Heh, so I just wanted to push the fix and you had already pulled. :)
15:36:38gokr1But sure, if it can run before I get the result back - then I can be screwed.
15:37:11Araqthat shouldn't happen. that said, there was some bug report about it
15:37:51gokr1The annoying thing is that I ... seem to be able to get a segfault even when only using ... hello. Which just returns 42. I need to test more closely.
15:38:21*silven quit (Quit: No Ping reply in 180 seconds.)
15:38:23fowlgokr1, are you sure nimrod
15:38:33fowlnimrod's int is the same as smalltalk's long?
15:38:55gokr1This is 32 bit, so an int is 32 bits in Nim I gather.
15:38:58fowlyou could use the type "clong"
15:39:33fowlint in nimrod is native-size, so if you have a 64 bit processor its 8 bytes
15:39:35*silven joined #nimrod
15:39:48gokr1And then on the Squeak side - a long is a 32 bit signed.
15:40:03gokr1fowl: Certain even if I compile as 32 bits?
15:40:35Jehan_gokr1: an int is int_ptr_t in Nim.
15:40:57*khmm joined #nimrod
15:41:06*jlebrech joined #nimrod
15:41:13Jehan_I.e. sizeof(int) == sizeof(pointer)
15:41:38jlebrechI want to write webapps with nirmod which splits off into client/server code.
15:41:53gokr1So if I use -m32, doesn't that make int and pointer 32 bits?
15:42:38fowlgokr1, well -m32 is an option for the c compiler and linker
15:42:42Jehan_gokr1: Correct.
15:42:55Jehan_You may still have to specify --cpu:...
15:42:56fowlif anything would affect nimrods int size it would be --cpu:i386 but you should double check that
15:43:23gokr1Jehan_: I do that too.
15:43:58fowlgokr1, just do echo(sizeof(int)) and see
15:46:22Jehan_nimbase.h has a check that will stop compilation if Nim and the C compiler disagree on the size of int.
15:46:52fowlhey I dont see where you call nimrod_init or whatever
15:47:53*gokr1 quit (Ping timeout: 240 seconds)
15:49:18fowli cant find the documentation talking about that though..
15:49:27fowlgoing to work, have a good day all
15:50:03Jehan_With respect to the GC, the GC needs to know the extent of the stack. That's done from NimMain() usually.
15:50:55*khmm quit (Ping timeout: 244 seconds)
15:51:25Jehan_I've forgotten what needs to be done for threads, though.
15:53:33*EXetoC joined #nimrod
15:53:57*khmm joined #nimrod
15:54:46*q66[lap] joined #nimrod
15:57:09*kemet joined #nimrod
15:59:09*bogen joined #nimrod
15:59:28*kemet quit (Client Quit)
15:59:49*gokr joined #nimrod
16:00:14*untitaker quit (Ping timeout: 250 seconds)
16:05:59*untitaker joined #nimrod
16:11:04gokr_it said 4 btw (sizeof)
16:11:45gokr_And niminit is called automatically for a lib I hope?
16:12:30gokr_In fact... it might be stable now. I think it was me unloadin reloading causing it to go boom
16:12:42gokr_later
16:26:05*superfunc joined #nimrod
16:26:55gokrAraq: I think its stable - as long as I don't do "Smalltalk unloadModule: 'testlib' " and then try again (causing a reload of the lib). But that is probably a Squeak thing.
16:27:02gokrRunning a fat test now
16:27:18superfuncSup gokr
16:31:28*brson joined #nimrod
16:32:46*BitPuffin quit (Remote host closed the connection)
16:34:43*q66[lap] quit (Quit: Textual IRC Client: www.textualapp.com)
16:42:43*vendethiel quit (Ping timeout: 255 seconds)
16:44:20*q66[lap] joined #nimrod
16:44:31*vendethiel joined #nimrod
16:45:58*khmm quit (Ping timeout: 256 seconds)
16:46:43*mbenadda_ quit (Quit: Be back later ...)
16:47:11*mbenadda_ joined #nimrod
16:52:19*gokr_ quit (Ping timeout: 245 seconds)
17:05:15*vendethiel quit (Ping timeout: 258 seconds)
17:07:13*vendethiel joined #nimrod
17:11:03NimBotAraq/Nimrod master 9f99dd0 def [+0 ±1 -0]: Add list comprehensions to future module
17:11:03NimBotAraq/Nimrod master c7898a0 def [+0 ±1 -0]: Extend list comprehension documentation
17:11:03NimBotAraq/Nimrod master 2476ee0 def [+0 ±1 -0]: Add -lm for fesetround and fegetround
17:11:03NimBotAraq/Nimrod master c0422ae def [+0 ±2 -0]: Move floating point rounding and exceptions handling to math... 1 more lines
17:11:03NimBot53 more commits.
17:13:11AraqJehan_: please think about my .dispatcher proposal. bigbreak is the right time to fix this language wart
17:13:48Araqpseudo-randomly selection of what's the base for the effect system is really not good enough
17:22:31*q66[lap] quit (Quit: Textual IRC Client: www.textualapp.com)
17:29:04*vendethiel quit (Ping timeout: 250 seconds)
17:29:44*mko joined #nimrod
17:35:36*vendethiel joined #nimrod
17:58:19*mko quit (Read error: Connection reset by peer)
17:58:37*mko joined #nimrod
18:02:44*mbenadda__ joined #nimrod
18:03:34*Matthias247 joined #nimrod
18:06:37*mbenadda_ quit (Ping timeout: 260 seconds)
18:07:41*mbenadda__ quit (Ping timeout: 264 seconds)
18:10:30*jlebrech quit (Remote host closed the connection)
18:11:17ldleworkboo to closing my PR
18:11:22ldleworkjust kidding :)
18:12:42*BitPuffin joined #nimrod
18:12:53*Jehan_ quit (Quit: Leaving)
18:19:19*vendethiel quit (Ping timeout: 265 seconds)
18:20:25ldleworkDoes anyone know, assuming I have libtcod installed correctly to my system, how I can compile this and the samples? https://github.com/Vladar4/libtcod-nim
18:29:55*vendethiel joined #nimrod
18:38:33ldleworkDoes the csources have a bigbreak branch?
18:39:29ldleworknm
18:51:53*vendethiel quit (Ping timeout: 240 seconds)
18:58:46*vendethiel joined #nimrod
19:02:09*BitPuffin quit (Ping timeout: 260 seconds)
19:05:13ldleworkAraq: when compiling a newly cloned bigbreak: https://gist.github.com/dustinlacewell/a4727e9f7d6d0989ff76
19:07:23ldleworkWhich branch should I be using?!
19:07:30ldleworkI see commits landing on master...
19:07:40ldleworkI thought bigbreak was where current was going
19:16:42dom96bigbreak
19:18:18Araqldlework: thanks for reporting
19:18:34Araqlooks like it's only gcsafe due to the better inference that I implemented
19:18:57Araqwhich means bootstrapping fails unless you use Araq's binaries
19:19:06Araqhi dom96
19:19:14Araqldlework: well I merged devel to master
19:19:26Araqand will merge bigbreak to devel
19:19:31*Mat3 joined #nimrod
19:19:34Mat3hello
19:19:40Araqhi Mat3
19:19:54Mat3hi Araq
19:20:10dom96hey Araq
19:20:46*Hakaslak joined #nimrod
19:22:29ldleworkAraq: I'm not sure what that means. What should I do to compile a new version?
19:22:51Araqldlework: wait an hour until I fixed it
19:23:12ldleworkoh okay
19:23:13ldlework:)
19:39:23*q66[lap] joined #nimrod
19:40:22*q66 joined #nimrod
19:41:54*vendethiel quit (Ping timeout: 265 seconds)
19:44:36*vendethiel joined #nimrod
19:52:00*Jehan_ joined #nimrod
19:52:38*superfunc quit (Quit: Connection closed for inactivity)
19:54:12Jehan_Araq: Why is initializing the stack bottom disabled when emulatedThreadVars() is on?
19:56:03AraqJehan_: it's not disabled, but it's done later iirc
19:56:42Araqfor some codegen reasons (setStackBottom uses the shadow stack which uses thread local storage which is emulated)
19:56:57Jehan_Hmm.
19:57:08Araqbut I think we should get rid of that
19:58:53Jehan_Hmm, setStackBottom does not do anything other than casting both the old and new to int and comparing them and using the lower/higher (depending on stack direction) value.
20:00:13ldleworkAraq: do you mind pinging me?
20:00:40Jehan_I found out when I was looking at how this was initialized for thread stacks and finding that the call for the main stack disappeared entirely.
20:09:54*ARCADIVS quit (Quit: ARCADIVS)
20:10:00*q66[lap] quit (Quit: Textual IRC Client: www.textualapp.com)
20:11:44*q66[lap] joined #nimrod
20:13:31Araqldlework: sure I'll ping you
20:14:23*Hakaslak quit (Ping timeout: 240 seconds)
20:28:06*Francisco quit (Ping timeout: 256 seconds)
20:30:18*vendethiel quit (Ping timeout: 265 seconds)
20:34:12*Francisco joined #nimrod
20:36:17*vendethiel joined #nimrod
20:41:50*superfunc joined #nimrod
20:54:11*will quit (Remote host closed the connection)
20:57:47*vendethiel quit (Ping timeout: 265 seconds)
21:00:26*eigenlicht quit (Ping timeout: 272 seconds)
21:03:24*mbenadda__ joined #nimrod
21:05:06*eigenlicht joined #nimrod
21:07:54*mbenadda__ quit (Ping timeout: 250 seconds)
21:11:37*vendethiel joined #nimrod
21:13:52*Joe_knock joined #nimrod
21:19:51*Hakaslak joined #nimrod
21:32:28ldleworkAraq: any luck?
21:33:46Araqldlework: sorrry, got distracted
21:33:51Araqlet me upload now
21:40:38*Mat3 quit (Quit: Verlassend)
21:42:07*mbenadda__ joined #nimrod
21:42:14*mbenadda__ quit (Client Quit)
21:42:25*mbenadda_ joined #nimrod
21:43:30*superfunc quit (Quit: Page closed)
21:49:19NimBotnimrod-code/csources bigbreak 2c54ca5 Araq [+46 ±2518 -0]: updated csources for bigbreak
21:49:28Araqldlework: ping
21:49:33ldleworkyay
21:51:37NimBotAraq/Nimrod bigbreak 52a3acb Reimer Behrends [+0 ±1 -0]: Fix method recursion bug.... 2 more lines
21:51:37NimBotAraq/Nimrod bigbreak 1fc8bab Reimer Behrends [+0 ±1 -0]: Reset location when creating a method dispatcher... 8 more lines
21:51:37NimBotAraq/Nimrod bigbreak f3d7158 Simon Krauter [+0 ±1 -0]: Fix terminate() and add kill()
21:51:37NimBotAraq/Nimrod bigbreak bce2d57 Reimer Behrends [+1 ±0 -0]: Added test case for recursive methods.
21:51:37NimBot5 more commits.
21:52:55gokrOn my Squeak2Nim calling - 2 hours later and about 8 billion calls. Did the same with the first code using "char*" for a billion calls and that worked too. So it all works.
21:53:15gokrIt was that unloadModule: thingy that isn't working. But who needs to unload :)
21:54:02ldleworkwow that was a lot of changes I just pulled to csources
21:54:06Araqit's no surprise that unloading doesn't work
21:54:48gokrI also checked the FFI code - and yes, it copies char* arguments going to Nim - and deallocates them on return, and also copies any char* returned from Nim.
21:55:24ldleworkAraq: I get the same error
21:55:34ldleworkdo I need to reclone, or just pull, rebuild csources, then koch
21:56:36Araqpull from bigbreak
21:57:12Araqthen do:
21:57:15Araqbuild.sh
21:57:33fowlgokr, you fixed the segfault issue from this morning?
21:57:39Araquse the newly produced 'nim' exe to compile koch and then bootstrap
21:57:49gokrfowl: Yeah, it seems there really was no issue.
21:57:56Araqldlework: the binary's name is now 'nim'
21:58:10ldleworkah
21:58:11gokrThe problem was me doing "Smalltalk unloadModule: 'testlib' "
21:58:12ldleworkthat worked
21:58:23fowlah
21:58:30gokrfowl: That unloads the .so, and upon next call it will reload it.
21:58:34gokrBut then... BOOM.
21:58:56gokrIf I just don't do that (as the doctor says) - it all works fine.
21:59:08gokrI am soon pushing an updated article.
22:00:22gokrNow... concat() works because: a) Squeak copies the strings sent to temp memory before passing to Nim b) Nim doesn't GC the returned char* until next time we call Nim at the earliest c) Squeak immediately copies the bytes returned from Nim.
22:00:46Araqyes. that's how it should be
22:01:07AraqVarriount, Jehan_, dom96 etc... please any PR now against bigbreak
22:01:26Araqmerging devel to bigbreak is getting tedious
22:01:43Araqor maybe I should merge bigbreak to devel?
22:01:52gokrfowl: So I'm a happy clam :)
22:02:00Araqoh well, what can go wrong?
22:05:16Jehan_Araq: Sure, except for showstoppers, I take it?
22:06:30Jehan_W.r.t. merging bigbreak into release, wouldn't that incorporate all the breaking changes into 0.9.8 or whatever?
22:06:36Jehan_s/release/devel
22:08:03Araqwell I need to update master, it should be 0.9.7
22:08:19Araqdevel will be bigbreak, so 0.10.0
22:08:26Jehan_Okay, I see.
22:08:30Araqwhich is not released so hrm
22:08:52Jehan_In which case, just merge devel into master and rename bigbreak to devel?
22:09:19AraqI already merged it into master today
22:09:30gokrThanks everyone for helping on that Squeak2Nim thing btw, letting that go for now, but yet another article :)
22:09:36Araqah, I didn't know one can rename
22:10:55Araqwell we need an odd number, so it's 0.10.1, right?
22:11:06Jehan_Araq: Still not sure about the value of a special syntax for list comprehensions.
22:11:29AraqJehan_: for me 'future' means 'playground'
22:11:31Jehan_Hmm, 0.10.-1 doesn't work, I think.
22:11:38Jehan_Araq: Yeah, that's understood.
22:14:47Araqwell we can't release 0.10.0 anyway ... lots of people already have a compiler that pretends to be 0.10.0
22:14:58Araqso it'll be 0.10.2 then
22:15:49VarriountAraq: We're releasing bigbreak?
22:16:07VarriountI was under the impression that (eventually) bigbreak would just be merged into devel, then deleted.
22:16:38AraqVarriount: not tonight. but since it's named "devel" we can merge it tonight, right?
22:16:39Jehan_Varriount: devel is constantly being merged into bigbreak, so they should be pretty much in sync.
22:16:51VarriountAraq: I'll prioritize issues when I get home.
22:17:03Araqsure no worries
22:19:35AraqJehan_: how can I rename branches?
22:20:15flaviuAraq: git branch --help; /rename
22:20:15Jehan_Araq: git branch -m
22:20:42Jehan_Note that if you rename to an existing branch, that other branch will be deleted.
22:21:05flaviuJehan_: that's -M
22:21:14Jehan_So, you'll have to merge devel into master first.
22:21:53ldleworkMan this is ridiculous. I compiled libtcod a few weeks ago. Haven't touched it. And now recompiling gives me errors.
22:22:16Jehan_flaviu: It's what happens if you rename, I didn't say it's what happens if you rename using "git branch -m" :)
22:23:00Jehan_What I was trying to communicate was that in git, branches aren't branches in the traditional sense, but simply names that point to specific commits.
22:23:28ldleworkCan anyone help me figure out why this isn't working? https://gist.github.com/dustinlacewell/078ff38ca8b300a936bd
22:23:35ldleworkShouldn't RShift be something that's part of SDL?
22:24:25Araqldlework: bigbreak is case sensitive (partially), so it should be rshift
22:24:48ldleworkAraq: I'll try that thanks for the hint
22:25:12Araqand please make PRs against any babel/Nimble package that you encounter
22:25:54Araq*any broken
22:26:21reactormonkyup, bigbreak does deserve its name.
22:26:57ldleworkAraq: it worked!
22:30:06ldleworkhmm
22:30:18ldleworkBut now the BSP example causes it to hang
22:30:32ldleworkspinning at 100%
22:30:34ldleworkyikes
22:31:20ldleworkaaaaand, SIGSEGV: Illegal storage access. (Attempt to read from nil?)
22:31:43ldleworknote: I have *not* git-pulled on libtcod-nim (there haven't been any updates anyway)
22:33:09ldleworkI guess I should just ignore it?
22:35:08ldleworkI think it is because its using the nil keyword?
22:35:12ldleworkwas nil deprecated?
22:36:49flaviuThat'd be a bit crazy
22:36:51EXetoCyes, as a synonym for discard
22:37:22ldleworkEXetoC: so do you check if a value is 'discard' or?
22:38:22EXetoCno it was deprecated for that situation only. there's still the value nil
22:38:35*mbenadda_ quit (Read error: Connection reset by peer)
22:39:03*mbenadda_ joined #nimrod
22:39:04EXetoC"if bla: nil" discard should be used in that situation. both could be used before
22:39:29EXetoCthough you still need nil in type variant blocks. I'm sure that's unintended
22:42:01fowldiscard makes slightly less sense there EXetoC
22:43:21EXetoCnil just being a value makes sense to me. it's not really one in that situation imo
22:47:25EXetoCit's just for the sake of satisfying the grammar rules in both cases, right?
22:49:26ldleworklol did anything happen in bigbreak that would change the result of arithmatic?
22:49:34*Jehan_ quit (Quit: Leaving)
22:51:50ldleworkAll the numbers in this program are just way too huge now
22:51:50EXetoCI hope 1 + 1 still equals 2
22:52:01ldleworkwhich is why it hangs now
22:52:14ldleworkbecause its trying to generate a map of billions by billions
22:53:02flaviuldlework: gdb?
22:53:16ldleworkflaviu: I dont' know how to use it very well
22:53:36flaviuUnfortunately I don't either :P
22:57:50fowlweird arithmetic? i doubt it
23:02:23*hopla joined #nimrod
23:03:08hoplaI am porting sse/avx intrinsics. Is there anyway to have underscore as a first character for types and functions (just to have same naming as C)?
23:04:25flaviuhopla: No, but there is a way to avoid mangling with a custom name.
23:04:27fowlhopla, use the importc pragma
23:04:31ldleworkOkay so, calling bsp_new_with_size(0, 0, SAMPLE_SCREEN_WIDTH, SAMPLE_SCREEN_HEIGHT) results in a BSP node with it's Y set to some huuuuuuuuuuuuuuuge number.
23:04:50flaviuldlework: sounds like confusion with signs
23:05:12ldleworkflaviu: like signed vs unsigned not being checked at the nim/c border?
23:05:16ldlework..or something?
23:05:39hoplafowl: this is what I am doing. But the nim name cannot have underscore as a first argument. See: https://gist.github.com/anonymous/e6ce63727e543b17a4e7
23:05:51fowler flaviu is right you can't have an identifier like _foo at all in nimrod
23:05:52flaviuldlework: that sounds about right. Is there any code I can take a look at?
23:06:06hoplaflaviu: ok!
23:06:29fowlhopla, thats correct, also use header:"<xmm...>" on the types instead of emitting #include
23:06:48flaviuYep, last time I looked at the compiler that was coded into the parser, without any sort of flag on it.
23:06:50hoplafowl: thanks!
23:06:59hoplafowl: I'll do it.
23:07:12*Francisco quit (Ping timeout: 244 seconds)
23:07:50*Francisco joined #nimrod
23:07:51flaviuhopla: If you'd like, you can patch the compiler so that it'll work in 99% of cases. You could get issues with hygienic macros if you tried hard enough though.
23:08:26hoplaAlso, there will be need for the user to enable these features for gcc or msvc (using compiler flags). Is there a proper way to do it with nim (forcing flags when required)? This is true for sse/sse2 in 32 bits and then for everything else for x64 and x64.
23:08:37hoplax86 and 64
23:09:01hoplaflaviu: I am fine with mm_add_ps. Just a matter of taste anmd compatiblity I guess.
23:09:04fowlhopla, yes use the passC/passL pragmas to pass options to the c compiler or linker
23:09:51hoplafowl: Is it going to be per module? Basically, if I use xmmintrin module, then everything using it must turn the flags on?
23:10:15fowlno just in that module
23:10:16*BlaXpirit-UA quit (Quit: Quit Konversation)
23:10:53ldleworkflaviu: does Nim even distinguish between uint and int?
23:11:05Araqldlework: yes it does
23:11:19ldleworkWhen I try to set the struct property to uint I get,
23:11:21ldleworksamples.nim(859, 14) Error: type mismatch: got (int literal(1), uint)
23:11:24hoplafowl: can I create a macro in the module that we can use then in the module including it. this macro will turn the flag on then. Is that a good way to do it?
23:11:33flaviuyeah, and I think that it uses that info for the signed shifts
23:11:42flaviuldlework: import unsigned?
23:11:49fowlhopla, i dont think you need to do that
23:12:22Araqhopla: identifiers starting with _ are ugly and hence not allowed
23:12:35ldleworkhmm I'm starting to get confused :P
23:13:45fowlldlework, unsigned stuff is in a different module (unsigned)
23:13:58ldleworkfowl: sure but I'm not really sure what to change
23:14:09*hopla2 joined #nimrod
23:14:35fowlbrb
23:14:43*Trustable quit (Quit: Leaving)
23:14:45ldleworkIt seems odd that I have to handle unsigned things so explicitly
23:14:56ldleworkAlso did this change? Because libtcod's examples were compiling fine before...
23:14:56hopla2Araq: ok for me. I don't care :-)
23:15:05Araqalso it's usually better to introduce names that make sense as opposed to copy the names from C
23:15:34fowlnooo a c wrapper should have the same interface as it does on c
23:15:38flaviuAraq: I've mostly seen 1:1 wrappers, and then a higher level wrapper on top that
23:15:49*hopla quit (Ping timeout: 246 seconds)
23:15:53hopla2Araq: they are pseudo for instructions name. _mm_add_ps is actually addps
23:16:01hopla2I can pick up addps
23:16:08Araqhey, you can even introduce operators instead of mxopcAddFluffy
23:16:34ldleworkI have a feeling this is because C uses unsigned ints by default?
23:16:38Araqfowl: it depends on whether that even counts as a "C wrapper"
23:16:40ldleworkSo likely libtcod is using unsigned ints
23:16:42hopla2Araq: I want to have plain wrappers (as close as possible from c) and then wrappers
23:16:51ldleworkso I will have to convert the entirety of the source to use explicitly denoted unsigned ints?
23:16:56Araqldlework: C doesn't use unsigned by default, whatever that means
23:17:04ldleworkAraq: https://github.com/Araq/Nimrod/wiki/Nimrod-for-C-programmers
23:17:18ldleworkUnsigned ints | Yes (by default) | Yes (not by default)
23:17:28Araqso?
23:17:40hopla2for example something like that: https://github.com/embree/embree/blob/master/common/simd/ssef.h
23:17:43Araqohhh a wiki page with an error. never seens that before
23:17:47Araq*seen
23:18:13hopla2I like embree simd code. It is clean and well abstract but I would like to have "bare metal" intrinsics also
23:20:08hopla2Araq: I don't care about '_'. If used nowhere, I agree it is just ugly to have an exception for that.
23:20:49ldleworkI'm getting, samples.nim(859, 14) Error: type mismatch: got (int literal(1), uint)
23:20:55ldleworkif minx > 1: dec(minx)
23:20:59ldleworkunsigned is imported
23:21:50Araqldlework: well, you can't really do signed -= unsigned
23:21:58Araqmaybe learn about type conversions
23:22:11ldleworkThis is worrying.
23:22:31ldleworkAll of the other bindings, go, rust, etc, just have it defined as "int" and it works
23:22:38ldleworkFurther, this worked before I upgraded to bigbreak
23:23:26Araqyeah I can imagine why
23:23:46ldleworkAraq: you can?
23:24:18Araqsome wrapper has UInt, somewhere it's uint, now it's system.uint instead of wrapper.UInt
23:24:30Araqand the misery starts
23:24:45Araqthe fix is to update the wrapper
23:25:05ldleworkAraq: by wrapper you mean 'libtcod'
23:25:12AraqI guess so
23:25:15flaviuAraq: Not being able to do `signed -= unsigned` sounds like a misfeature at best
23:25:43ldleworkHere is how the wrapper's structure is defined, https://gist.github.com/dustinlacewell/14b318b193b7e05c7535
23:25:44*superfunc joined #nimrod
23:26:05ldleworkIts the X, Y, W, H that seem to get enormous values when this structure comes back from the C barrier back into Nim
23:26:09EXetoCflaviu: don't like explicit casting?
23:26:16Araqflaviu: I don't care. if you wanna play the game "I don't care about types or proper range checking or bugs" you're free to continue to use C
23:26:47ldleworkAraq: so, this wrapper never defined it as UInt or anything, it was always just 'int'
23:27:22Araqmost serious developers like fewer implicit conversions for the numeric type zoo, afaict
23:27:48ldleworkIt does use 'uint8' in some places not relevant to this behavior
23:28:27Araqldlework: well gist it and we may be able to help you.
23:31:10hopla2Other good naming can be to take something like LLVM intrinsics names: x86_sse_add_ps
23:32:41Araqwhere "good naming" as usual ignores usage statistics
23:33:16Araqhint: how often do you want to read x86_sse_ in your SSE heavy code?
23:33:20flaviuEXetoC: I don't really mind explicit casting, but looking at that it's not really a good idea - looking at context to decide to convert or not is ridiculous. however, `let v: int32 = uint8(32)` is perfectly safe and not implicit, while `float32(0x7FFF_FFFF_FFFF_FFF)` is done implicitly and is unsafe
23:33:31hopla2I am not sure. We can go for short like addps or more explicit.
23:34:51hopla2Araq: I don't really mind honestly. I guess it is more about consistency with the rest of nim and I am a nim newbie. So, pick your choice :-)
23:35:18Araqname the module x86_see and the proc addps
23:36:23Araqldlework: well the libtcod-nim wrapper is almost a year old and hasn't been updated afaict
23:36:30ldleworkAraq: that's what I'm attempting to do
23:36:41ldleworkAraq: I have every sample working with bigbreak except this last one
23:36:43*hsuh quit (Ping timeout: 255 seconds)
23:36:48ldleworkI want to take over maintainence ownership of the lib
23:36:51*johnsoft quit (Ping timeout: 272 seconds)
23:37:01ldleworkAraq: I'm committing my updates to my own fork now
23:37:06Araqoh ok, sorry
23:37:06*johnsoft joined #nimrod
23:37:35ldleworkokay, https://github.com/dustinlacewell/libtcod-nim
23:37:52ldleworkIf you compile libtcod first, then go into samples and do ./build-samples.sh
23:37:54ldleworkIt should compile fine
23:38:10ldleworkrun the samples and go down to BSP example, and I have logged some output
23:38:20ldleworkYou can notice that the X, Y values for the node are super huuuge
23:38:43*askatasuna quit (Quit: WeeChat 1.0.1)
23:39:06ldleworkThe BSP struct that we're passing to C and getting back, is defined in libtcod/lib/bsp.nim
23:39:16*hopla2 quit (Ping timeout: 246 seconds)
23:39:34ldleworkThe code that uses it is in libtcod/samples/samples.nim line 945
23:39:34*hopla joined #nimrod
23:39:45ldleworkThis is where we get back the BSP object from the C side
23:39:48hoplaAraq: so go for it. Thanks!
23:39:52ldleworkIts attributes are already huge at this point
23:40:08ldleworkSo the C must be creating the struct and passing us back a pointer to it, and we're interpreting the attributes as the wrong int type
23:40:09hoplaAraq: BTW, I think we really need a forceinline/always_inline. inline is a bit of disaster in most C compilers. It is kind of critical for this kind of code to get inlined for sure (well, msvc can be still reluctant but gcc / clang / ICC will comply)
23:41:15Araqhopla: BTW I think you should learn to read assembler code. Most C compilers manage to inline 1-liners, even *without* inline.
23:42:07Araqldlework: what's the struct's name?
23:42:11Araqwhere is it declared?
23:42:12*hsuh joined #nimrod
23:43:20hoplaAraq: please don't prejudge me. C compilers can fail to inline leafs in the call tree. __forceinline is the rule for this kind of code and avoid any problem with C compilers
23:44:18Araqsounds to me like some random rule that stopped making sense a decade ago
23:44:40hoplaAraq: open xmmintrin.h from Clang and see by yourself how they are defined.
23:45:09Araqso? what does that prove?
23:45:22Araqthat people rarely touch what works
23:45:27fowlldlework, try making bsp_new_with_size take cint
23:47:31hoplaAraq: please do not start a flameware. It proved nothing. It is just a good practice and avoid any inlining issue. I don't understand the problem you have with that.
23:47:46*mbenadda_ quit (Quit: Be back later ...)
23:48:35fowlldlework, change the declaration in bsp.nim i mean
23:49:29Araqit's not "good practice". it's archaic. what if compiler start to screw up forceinline? do we then have reallyforceinline? and is that then a "best practice"?!
23:50:13Araqhowever you're free to patch N_INLINE so that it maps to __forceinline ...
23:51:21ldleworkfowl: compiles, crashes the same way
23:51:31ldleworkfowl: what is cint?
23:51:38hoplaAraq: I am practical. I don't care. I know pretty well LLVM. And this is forceinline: https://github.com/llvm-mirror/llvm/blob/master/lib/Transforms/IPO/InlineAlways.cpp. It is brutal and simple. This: https://github.com/llvm-mirror/llvm/blob/master/lib/Transforms/IPO/InlineSimple.cpp is full of bullshit heuristics. I am sorry. This is life of backends. Not my fault.
23:51:42ldleworkAraq: I mentioned that the struct is defined in bsp.nim
23:52:31VarriountAraq: I'm home.
23:53:17*Sembei quit (Ping timeout: 264 seconds)
23:53:46hoplaAraq: I am fine with inline btw. But, I would like to add force_inline ABI. Would it be possible? I do not think forceinline for everything is a good idea. Sounds more like a terrible idea actually
23:53:48fowlldlework, cint is "int" in c, wrappers should use it. gcc on my machine uses 32 bit ints but nimrod uses 64
23:55:20*xenagi joined #nimrod
23:57:09ldleworkfowl: welllllll, that fixed the issue but I still get a segfault :(
23:57:25Araqhopla: mapping .inline to __forceinline (if available) is fine with me. I don't see the point in a "maybe inline, maybe not" inline directive
23:57:37ldleworkIE, its printing out normal values now, but it crashesh
23:57:56fowldo you get a stacktrace
23:58:05Araqhopla: the "maybe" is what a modern optimizer does already anyway
23:58:06ldleworkHow do you tell where the: SIGSEGV: Illegal storage access. (Attempt to read from nil?) is happening?
23:58:10ldleworkfowl: no :(
23:58:15fowlcompile with -d:debug
23:58:18ldleworkoh okay
23:59:26ldleworkfowl: could not load: libtcod_debug.so
23:59:38ldleworkfowl: I recompiled libtcod with -d:debug but it doesn't produce .so's