<< 29-06-2013 >>
00:02:24*q66 quit (Quit: Leaving)
00:35:12*DAddYE quit (Remote host closed the connection)
00:55:08*fowl quit (Ping timeout: 245 seconds)
02:05:10reactormonkwould someone explain to me why proc pgm_read_byte(pointer: prog_ptr): byte {.importc: "pgm_read_byte", header: "avr/pgmspace.h".}
02:05:18reactormonkproduces an "invalid pargma"
02:05:26reactormonkor should I post it on stackoverflow for karma? ^^
02:36:38*DAddYE joined #nimrod
02:40:49*DAddYE quit (Ping timeout: 246 seconds)
02:56:01*DAddYE joined #nimrod
03:17:21*BitPuffin quit (Ping timeout: 248 seconds)
03:17:39*DAddYE quit (Read error: Connection reset by peer)
03:18:15*DAddYE joined #nimrod
03:45:19*DAddYE quit (Read error: Connection reset by peer)
03:47:56*DAddYE joined #nimrod
04:46:36*Associat0r joined #nimrod
04:46:36*Associat0r quit (Changing host)
04:46:36*Associat0r joined #nimrod
05:13:26*OrionPKM joined #nimrod
05:18:01*OrionPKM quit (Ping timeout: 256 seconds)
06:13:57*OrionPKM joined #nimrod
06:18:28*OrionPKM quit (Ping timeout: 268 seconds)
06:22:58Araqreactormonk: compiles for me ... maybe the reported line is wrong?
06:44:10reactormonkAraq, http://sprunge.us/BGMZ
06:44:15reactormonkhttp://pastie.org/private/l3uqmermhmplsv4nmc5txw
07:06:08Araqreactormonk: it's a compiler bug
07:09:21NimBotAraq/Nimrod master c1952db Araq [+0 ±1 -0]: bugfix: pragmas allowed for implicit generics
07:09:26Araqthere you go
07:13:59*apotheon_ joined #nimrod
07:14:27*OrionPKM joined #nimrod
07:16:13*apotheon quit (Disconnected by services)
07:16:25*apotheon_ is now known as apotheon
07:16:25*apotheon quit (Changing host)
07:16:25*apotheon joined #nimrod
07:18:08*Raynes_ joined #nimrod
07:18:22*Trix[a]r_za quit (Ping timeout: 276 seconds)
07:18:23*Raynes quit (Ping timeout: 276 seconds)
07:18:25*Roin quit (Ping timeout: 276 seconds)
07:18:28*Trixar_zb joined #nimrod
07:18:54*OrionPKM quit (Ping timeout: 268 seconds)
07:20:00*Roin joined #nimrod
07:37:00*Raynes_ is now known as Raynes
07:37:01*Raynes quit (Changing host)
07:37:01*Raynes joined #nimrod
08:04:29NimBotAraq/Nimrod master d6e9249 Araq [+0 ±5 -0]: fixes lots of regressions
08:14:58*OrionPKM joined #nimrod
08:19:14*OrionPKM quit (Ping timeout: 252 seconds)
08:28:40NimBotAraq/Nimrod master 6b67811 Araq [+0 ±1 -0]: 2n attempt to fix niminst on the testing machines
08:48:57*DAddYE quit (Remote host closed the connection)
08:49:03*EXetoC joined #nimrod
09:15:29*OrionPKM joined #nimrod
09:19:43*OrionPKM quit (Ping timeout: 245 seconds)
09:36:09*Associ8or joined #nimrod
09:36:09*Associ8or quit (Changing host)
09:36:09*Associ8or joined #nimrod
09:38:13*Associat0r quit (Ping timeout: 256 seconds)
09:41:28*BitPuffin joined #nimrod
10:12:21*Associ8or quit (Quit: Associ8or)
10:17:01*q66 joined #nimrod
11:04:39dom96hello
11:16:25*OrionPKM joined #nimrod
11:18:46dom96hey OrionPKM, babel should work for you on Windows now.
11:20:47*OrionPKM quit (Ping timeout: 256 seconds)
12:03:36*Endy joined #nimrod
13:07:56*Endy quit (Quit: HydraIRC -> http://www.hydrairc.com <- Po-ta-to, boil em, mash em, stick em in a stew.)
13:15:20*Endy joined #nimrod
13:22:10*Associat0r joined #nimrod
13:22:10*Associat0r quit (Changing host)
13:22:10*Associat0r joined #nimrod
13:37:01EXetoCI've finally opened my first issue. Let's keep this ball rolling now :>
13:44:52EXetoCAraq: is it the dynamic dispatch that makes recursive method calls so bad in your opinion?
14:18:14AraqEXetoC: I never said anything about recursive calls, I don't mind recursion; however I do mind dynamic dispatch in general
14:18:46EXetoCI'm not sure what you said then
14:18:55EXetoCone more issue opened. I don't know how to reduce it some more
14:20:08Araqreducing to small programs is not as important as you think ;-)
14:20:25Araqunless it fails at runtime ...
14:23:12EXetoCright
14:30:05*Associ8or joined #nimrod
14:30:05*Associ8or quit (Changing host)
14:30:05*Associ8or joined #nimrod
14:31:16EXetoCI'm pretty sure that you said that nested method calls shouldn't be allowed. Am I wrong?
14:31:44AraqI said nested methods shouldn't be allowed:
14:31:45*Associat0r quit (Ping timeout: 256 seconds)
14:31:47Araqproc p() =
14:31:52Araq method m(...) = ...
14:33:39EXetoCand I was talking about recursive calls, which might be why I was confused
14:33:54Araqyeah
14:37:19EXetoCI don't know why you don't like virtual calls. I could do without it, but I might as well just not write boilerplate switch cases
14:38:18Araqthere is nothing "boilerplate" about explicit dispatching
14:38:44Araqyou wouldn't call "if" statements "boilerplate" either
14:39:22Araqand the difference between "can do pretty much anything" and "can do these X different things" is vast
14:40:12Araqespecially if you care about *reasoning* about programs
14:44:15EXetoCactually, I was more concerned with the potential overhead, but all you need is a jump table I guess
14:44:21EXetoCif I even used the correct term there
14:44:53Araqoh the old "virtual calls are potentially faster than switch" argument?
14:45:05Araqit's wrong. And has never been true.
14:46:07Araqthe virtual *loses* information in comparison to the switch; so it can never be faster in theory
14:49:05Araq(you can regain the information loss with a whole program optimizer though)
14:55:07EXetoCI don't know. I haven't even thought about this before. almost all languages I've used have had this 'class' keyword
14:58:51reactormonkAraq, ^^
15:01:12EXetoCwhich makes you think that it's more complicated than it actually is
15:02:43Araqit's more complicated than you think it is. MUCH more complicated. ;-)
15:05:01EXetoCwhat is? dispatching manually?
15:06:21Araqthe "class" keyword
15:06:24reactormonkEXetoC, can't find it, but there was a guy that optimized an object-oriented framework to non-OO, the main problem was that the objects contained function pointers intermixed with data, which leads to a wild amount of jumps when doing iterations
15:08:43EXetoCok
15:14:59EXetoCAraq: I meant compared to doing it manually, but then only for "classes" that can only do a certain amount of things
15:15:07EXetoCthen there's multiple inheritance, which I don't care for anymore
15:16:56EXetoCusing D and being limited to single inheritance is yet another thing that forced me to come up with less horrible designs
15:18:26*OrionPKM joined #nimrod
15:22:30*OrionPKM quit (Ping timeout: 240 seconds)
15:22:59AraqEXetoC: actually I like multiple inheritance moreso than class+interface but MI is somewhat hard to implement and there are always other things to do ...
15:31:51reactormonkAraq, compiles for now :-)
15:33:33reactormonkcopy_to = cast[ptr T](cast[int16](copy_to) + 1) produces copyto = ((NCSTRING*) ((NI16)(((NI16) (copyto)) + ((NI16) 1))));
15:33:51reactormonklooks good to me
15:35:56reactormonkAraq, can I rely on sizeof(T) to be the length of a string if T is a cstring or a string?
15:39:18EXetoCdoesn't sizeof just give you the size of the pointer?
15:39:50EXetoCyou get the length by calling len
15:43:18reactormonkEXetoC, well, some types have a length, some don't
15:44:39EXetoCand sizeof never gives you the length, so I don't know what you mean
15:47:49reactormonksizeof(cstring) gives me 8, whatever that means
15:48:33reactormonkbut I still don't know how to find out how much I have to copy over... good old loop until \0 apparently
15:48:35EXetoCit's a pointer
15:49:01EXetoC"proc len*(x: cstring): int {.magic: "LengthStr", noSideEffect.}" ?
15:49:40reactormonklib/system/arduino.nim(46, 9) Error: ambiguous call; both arduino.memcpy(pgm: prog_ptr[T], target: ptr T) and arduino.memcpy(pgm: prog_ptr[cstring], target: ptr cstring) match for: (prog_string, ptr cstring)
15:49:42reactormonkcrap.
15:52:53EXetoCyou could merge the two, and then use conditional compilation
15:53:59reactormonkshould be usable for both non-cstring and cstring
15:54:20reactormonkand specialized overload looks like the way to go for me
15:55:02*OrionPK joined #nimrod
16:10:11Araqreactormonk: sizeof returns the size, sizeof(cstring) == sizeof(pointer)
16:42:27*ack006 joined #nimrod
16:44:22Araqhi ack006, wb
17:34:34*fowl joined #nimrod
18:00:25reactormonkAraq, ok.
18:01:03reactormonkAraq, iirc this isn't the first time on overload?
18:13:45EXetoCfirst time?
18:16:13fowlhi
18:16:30fowlEXetoC, are you a windows guy
18:20:35reactormonkEXetoC, already asked Araq to implement that possibility
18:24:24EXetoCfowl: no
18:24:39EXetoCreactormonk: I don't know what you are referring to
18:26:08EXetoCfowl: I'm too leet for windows, aight!
18:26:10EXetoCwhy do you ask?
18:34:57*fowl- joined #nimrod
18:36:02fowlEXetoC, looking for a windows dude to check my wrappers on windows
18:36:07*fowl quit (Quit: Leaving)
18:36:16*fowl- is now known as fowl
18:36:22*fowl quit (Changing host)
18:36:22*fowl joined #nimrod
18:37:53dom96fowl: I can check them for you the next time i'm on Windows. Not sure when that will happen though.
18:38:24dom96OrionPK might be a Windows dude though
18:38:44OrionPKwindows/macos yeah
18:38:55*DAddYE joined #nimrod
18:39:29fowliirc some things didnt have binaries readily available
18:40:01fowland i fail at compiling
18:41:47fowlOrionPK, if you could do that for me i'd hella appreciate it
18:42:24fowli also want to host any necessary DLLs because they can be hard to find
18:42:57OrionPKI'll have some time later today, got a repo?
18:45:00fowlyeh github/fowlmouth/{nimlibs,nimrod-enet,nimrod-sfml,nimrod-chipmunk}
18:45:47OrionPKoh ok
18:45:58reactormonkEXetoC, the error abouve about the ambiguous call
18:46:25fowlOrionPK, its not a rush, whats your gh name i'll add you to the repos
18:46:37OrionPKonionhammer
18:48:08OrionPKive been meaning to look into some of your nimlibs anyway
18:48:47fowl:) its a mix of modules and wrappers
18:49:57*OrionPKM joined #nimrod
18:50:13OrionPKsilly mac
18:50:57*OrionPKM quit (Read error: Connection reset by peer)
18:50:58OrionPKafk
18:51:54EXetoCreactormonk: do you want the first one to be for everything except cstring?
18:52:24EXetoCif not, then how about removing the one that doesn't take any type parameters?
18:55:46EXetoCor maybe it doesn't optimize away branches that can be evaluated at compile-time
18:56:52*BitPuffin quit (Read error: Connection reset by peer)
18:56:57fowlEXetoC, hey im looking at your glfw3 wrapper
18:57:25fowlcast[ptr cushort](ramp.r) <- does this work? ramp.r is a seq[]
18:57:35fowlyou probably want cast[..](ramp.r[0])
18:57:43fowlramp.r[0].addr *
18:58:37fowlactually with ramp.r[0].addr that is ptr uint16 so you dont need the cast
18:59:25fowli think you should put high_level.nim in the same file as glfw3 and call it glfw3.nim
18:59:53fowlproc glfwHideWindow*(window: GLFWwindow) {.cdecl, importc: "glfwHideWindow", dynlib: glfwdll.}
19:00:35*q66 quit (Read error: Connection reset by peer)
19:01:00fowlreplace with : {.push callConv: cdecl, importc: "glfw$1", dynlib: glfwdll.} ; proc HideWindow*(arg: T) # done
19:01:04reactormonkEXetoC, exactly
19:02:05*q66 joined #nimrod
19:02:25fowloh and for ramp.r ramp will need to be passed as var
19:07:04EXetoCfixed. thanks
19:07:26EXetoCreactormonk: yes that seems useful
19:10:11EXetoCfowl: seqToPtr just casts to a pointer though, and that's used for comparing etc, so I guess it does
19:10:16EXetoCbut I might as well just do it this way
19:10:41fowlwhat's seqToPtr? ive never heard of it
19:10:57EXetoCit's in system.nim
19:11:08EXetoC"proc seqToPtr[T](x: seq[T]): pointer {.inline, nosideeffect.} = result = cast[pointer](x)"
19:11:19EXetoCI just looked at that, and I didn't think about doing it your way
19:11:47fowlim fairly certain pointers compare as ints
19:13:27fowlseqtoptr not in the doc for system.nim
19:14:00EXetoCno, it's private, but I often browse the source
19:15:20EXetoCfowl: isn't it a good idea to keep those interfaces separate? in order to keep it tidy when generating documentation
19:15:42EXetoCbecause I don't want the direct wrapper to be private
19:15:53fowlyea id say they compare like ints because things like this are possible : https://gist.github.com/fowlmouth/5860323
19:16:46EXetoCnot directly, but addr never crossed my mind
19:18:45fowlEXetoC, nah its easier to use if they are in the same file
19:19:23fowlor you could put the high level stuff in a when defined() section
19:20:17EXetoCfowl: A better solution seems to be to just export the symbols
19:21:40EXetoCassuming that it's possible to export everything in a module without having to specify everything that is in it
19:21:51EXetoCwill check
19:23:24EXetoCyup that's the best approach, right?
19:24:44fowlEXetoC, however you do it, call it glfw3.nim plz
19:24:57EXetoCfowl: that's the plan
19:26:12fowlwe have quite a selection of game-related libraries now
19:26:46EXetoCAraq: is there a reason why comma is used as a separator for import statements but not for object fields for example?
19:27:04EXetoCif so, does it have to do with simplifying the parser?
19:27:10Araqit is used for object fields: a, b: int
19:27:56EXetoCit's optional though, but fair enough
19:28:07Araqyou can use object[a, b: int ';'|',' z: string]
19:28:52fowlthat doesnt work for me
19:28:58fowltype tfoo = object[x, y: int, b: string]
19:29:09Araqhmm I thought I implemented that
19:29:11Araqoh wait
19:29:16Araqit's the other way round
19:29:21Araqyou can use indentation for 'tuple'
19:29:51fowlo ok
19:30:00fowlo ok
19:31:58Araqreactormonk: you know, if overloading is ambiguous, you can use different names for different things. I know, it's a crazy idea these days...
19:33:02Araqand give it a real name randmly leaving out vcals scks
19:42:18EXetoCfowl: all good? I might as well just keep the directory
19:44:26EXetoCthought maybe it should have the same name as the project
19:56:20fowlimport glfw3/wrapper is not needed
19:57:04fowlyou can call it glfw.nim and have glfw/high_level.nim and `import glfw3, glfw3/high_level` will work
20:25:08dom96I think it's better if glfw3 is the high level interface.
20:26:47fowlyea
20:30:55EXetoCit is
20:31:10fowlhow much of this high_level stuff is needed, like PWindow
20:31:58fowl let i = windowSet.find(newWindow(wnd))
20:32:19fowlallocates a new reference every time those callbacks are called, just to find the window
20:33:14fowlproc waitEvents*() =
20:33:14fowl glfwWaitEvents()
20:33:31fowljust use importc: "glfw$1" and have all glfw funcs like that
20:35:26EXetoCyep great feature, but the reason why I'm doing this is because I'm going to do error handling in pretty much every function eventually
20:36:04EXetoCas in throwing an exception if needed
20:36:49fowlok
20:37:00EXetoCI'm all ears though if you still think it's crap :>
20:37:02fowlwell please at least remove the glfw prefix from the API
20:37:17fowlEXetoC, i dont mind, as i can simply not use the PWindow stuff
20:37:39fowlthat find() call will never work though,
20:38:09fowlfind(new-item) new-item is created right there, its not going to be in windowSet
20:38:39EXetoCit does work, and let me look at the source so I can tell you why
20:39:27fowloh
20:39:37fowlbecause of == (l,r: PWindow)
20:42:02dom96Araq: What is the "standalone" OS meant to mean? Embedded, or "C stdlib is gone" ?
20:42:18dom96As I see it, it is the former and I need the latter.
20:42:49Araqit means "buggy and we don't know what it means"
20:43:36fowlEXetoC, PWindow is still a pretty fat type to be allocating on the fly like that
20:43:50fowlEXetoC, maybe you can use TTable[PWindowHandle, PWindow] instead
20:44:02dom96Araq: Can we come up with a better definition please?
20:44:18EXetoCyes, because of the callbacks, but I could also use another predicate for find, if it's even possible
20:44:19dom96Araq: I think we should create a separate system.nim for the standalone target.
20:44:31dom96Araq: Otherwise it becomes a huge mess.
20:44:34Araqdom96: that's what reactormonk tried
20:44:40Araqand it became a huge mess
20:44:55Araqthe current way is a huge mess
20:45:03Araqbut it's better than the alternatives I fear
20:45:07dom96why did it become a huge mess? what was the problem?
20:45:24fowlEXetoC, well you're using find everywhere right? trying to index them by the window handle, just use a table it will be a lot simpler
20:45:39Araqwell for a start you need to extract all the stuff that you DO need into includes
20:45:57Araqso that you can include what you need but then the deps between come and bite you
20:46:06Araq*between them
20:46:47Araqmy plan was to do it myself for programming my mindstorm
20:47:48dom96It seems to me that the compiler requires a lot of code which in turn assumes that the GC is present?
20:48:01Araqbut ... meh it's too much work, lets just hack around with 'defined' in system.nim
20:48:24Araqthe compiler only requires what you use
20:48:31dom96The question is why was it easy ~3 years ago?
20:48:53Araqit never was easy I think
20:48:55dom96I'm not sure how I use 'copyString' or 'newObj'?
20:49:08Araqdo you use 'raise'?
20:49:34fowlEXetoC, alzo i recommend for types that are pointer, use distinct pointer instead
20:49:37dom96Araq: no
20:50:45dom96My guess is that the compiler determines this incorrectly, or doesn't determine it at all.
20:50:46fowlEXetoC, otherwise foo(pointer) will match for GLFWmonitor and GLFWwindow, but really they are specialized pointers that only need to be dealt with from glfw
20:51:43dom96Araq: It was definitely easier, I mean, I believe I got it to boot my "OS"
20:52:42Araqwell we support 3 GCs now, dom96; perhaps that's "newish"
20:53:17Araqbut yeah the problem is "what does --os:standalone mean?"
20:54:10Araqdo we need --os:standalone and --os:embedded?
20:54:13dom96I say we should just get rid of it and tell users to create custom system.nim's
20:55:03Araqhmm indeed
20:55:36Araq--os:embedded doesn't cut it either, I'd use 4 char error messages for the mindstorm, but reactormonk doesn't even have a display
20:55:56dom96We cannot predict what some device supports or doesn't support.
20:56:04Araqso the basic IO needs to be quite flexible
20:57:22EXetoCfowl: ok, fixing now
20:57:30dom96ok, so now the question is why the compiler needs 'copyString' and other functions in system.nim?
20:58:59Araqok, let me share a secret
20:59:15AraqI do: nimrod c --os:standalone temp1.nim
20:59:29AraqError: system module needs 'addChar'
20:59:53Araqso I trace it with: nimrod c --verbosity:3 --os:standalone temp1.nim
21:00:21Araq...
21:00:22Araqlib/system.nim(44, 5) Hint: 2 [Processing]
21:00:24Araqlib/system.nim(48, 2) Hint: 2 [Processing]
21:00:25AraqError: system module needs 'addChar'
21:00:32Araqhmm line 48 is not the problem
21:00:44Araqoh I see, I need to turn on the hints :P
21:00:58Araqso I change it to: {.push hints:on.}
21:01:26Araqnow it produces:
21:01:29Araqlib/system.nim(1744, 4) Hint: 2 [Processing]
21:01:31AraqError: system module needs 'addChar'
21:01:45Araqand indeed around that line 'add' for characters is used
21:02:30Araq(and Yes, it's HARD to improve the "system needs" error message)
21:05:33dom96oh, I thought the reason these errors happen is because the compiler generates C code which uses it?
21:05:52Araqyep
21:05:59dom96I grepped for 'addChar' and in ccgexprs:1540 see that it's generated.
21:06:27dom96So basically I have to implement it...
21:06:29Araqnow grep in system/ and see where it's defined
21:06:53dom96what if it's something I cannot implement?
21:07:32Araqthen you better don't use the feature that triggers that code generation path
21:08:26dom96ahh, so it complains even if I don't use it?
21:08:33Araqno
21:08:41Araqit complains when you use it
21:08:57Araqas I said, use --verbosity:3 to determine where you use it
21:09:03dom96alright, thanks.
21:11:27Araq TResult* = enum Failure, Success # deprecate it?
21:11:40Araqwhich code uses that?
21:11:55Araqseems like a holdover from the pascal days
21:12:19dom96I think I might be using it somewhere actually
21:13:05Araqand why does IntMax32 include 'bool'? o.o
21:13:13dom96possibly in nimbuild
21:13:29Araqso that +% works for bool? wtf
21:13:47dom96lol
21:14:02dom96oh btw, nimbase.h is also not really suited for no C stdlib.
21:14:15dom96as it includes a lot of the C stdlib.
21:14:31Araqindeed; reactormonk got rid of <singals.h> at least
21:15:18Araqin fact, system should use "header" instead of "nodecl"
21:15:28Araqand then nimbase doesn't need to include these
21:18:18EXetoCfowl: that seems like the only significant overhead. it's fixed now
21:18:34EXetoCI should get rid of some boilerplate though. templates to the rescue
21:20:07fowlwhich overhead? the PWindow stuff?
21:20:22EXetoCyeah
21:20:50Araqdom96: if you use TResult, I won't deprecate it
21:21:27fowlhow dd you fix it
21:22:29EXetoCfowl: I used a table like you said
21:22:48fowlah good idea
21:22:56fowli can tell EXetoC is smart, he's going places ;)
21:23:41fowlEXetoC, my only other complaint about your code would be the way you typecast
21:23:45EXetoCc(;)-<
21:23:53fowlint(foo) is ughly, foo.int !
21:24:07dom96Araq: Yeah, I am using it in nimbuild
21:24:45Araqhmm --lib is flawed
21:25:26Araqif you override system.nim and leave out most of the things, they won't be available at compile time either
21:25:32dom96would {.exportc.} use copyString?
21:26:03Araqdom96: no
21:26:43dom96I guess when it hints at a proc header it means something inside the proc uses copyString?
21:26:56EXetoCfowl: smart? yay! I like you
21:28:41Araqdom96: yep.
21:29:08Araqand even then it's not that reliable ;-)
21:29:49*dom96 has no idea what could be using it
21:32:28EXetoCfowl: that has been dealt with my friend
21:32:43EXetoCmostly
21:32:48Araqdom96: which proc does it point to?
21:33:02dom96Araq: one in the file i'm compiling
21:33:34dom96what do the numbers after the 'Hint: ' mean?
21:33:57Araqcan't remember
21:34:56dom96https://gist.github.com/dom96/fadfa0e8441614358089
21:35:24dom96main.nim(16, 4) Hint: 4 [Processing]
21:35:37dom96Is the last hint before: Error: system module needs 'copyString'
21:36:39*Endy quit (Ping timeout: 256 seconds)
21:36:52Araqint8(count) can raise an exception for instance :P
21:38:14dom96gah
21:38:27dom96So I should use cast everywhere? :(
21:38:30Araqso ... you need to implement some exception handling that doesn't use strings or the heap
21:38:35Araqdom96: no
21:38:45dom96hrm, ok.
21:39:08dom96how do I do that? :P
21:39:46EXetoCfowl: ok what about this: handle.newWindow?
21:39:52EXetoCj/k
21:41:05Araqfowl: what's up with that SDL_main crap? they should have learned allegro's lessons ...
21:41:57fowlconstructors are the only place i dont use UFC, unless the constructor is instancing something (think box2d shape defs, shapedefinition.instantiate())
21:42:22EXetoC:>
21:43:19fowlAraq, i dunno ive never heard of that before gradha mentioned it, i think it might be only needed for windows
21:43:55fowlidk theres not any info on when you need to use it, and if all it does is initialize SDL (call SDL_Init ?) we probably dont need it at all
21:44:12Araqwell look at the latest forum post
21:44:17fowlok
21:45:56fowlwhich?
21:46:28dom96wow, when 'guiapp' is defined and an unhandled exception occurs it creates a messagebox on windows, nice.
21:46:33Araqthe raytracer
21:47:06Araqdom96: and even better, it's been this way for years and the stuff continues to work on windows
21:47:28Araqon macosx I'd have to rewrite it 3x by now
21:48:00Araqand the OS would tell me it runs in a terminal because that's what the boot sequence used
21:49:44fowl#ifdef SDL_MAIN_NEEDED
21:49:45fowl#define main SDL_main
21:49:45fowl#endif
21:52:02fowlidk
21:52:29fowlthis is not needed on linux, and i have no mac to test things out on
21:53:00fowlthis looks like it only applies to static linking
21:55:48*Associ8or quit (Ping timeout: 268 seconds)
21:58:27Araqdom96: excpt.nim contains raiseRangeError, raiseIndexError, raiseFieldError
21:58:38Araqmake these output the error somehow
21:58:47Araqthen you can use int8(x)
21:59:53dom96ugh, I just want to get this running, don't really care about errors.
22:00:11Araqwell then an empty implementation is fine too
22:00:45dom96that doesn't get rid of the need for copyString
22:00:58Araqit should
22:01:32dom96well it doesn't
22:02:33Araqdo you use --os:standalone or not?
22:02:54dom96oh, I see why.
22:23:49dom96Araq: What would 'newObj' be used by?
22:24:10Araq'new'
22:24:22Araqexception handling most likely
22:24:40Araqoh also by strings
22:26:31dom96hrm, well raiseFieldError has a 'string' param
22:27:05Araqthat shouldn't be an issue
22:27:11Araqunless you concat
22:27:17dom96nope
22:27:18Araqit only gets constant strings
22:27:24dom96my excpt.nim is extremely small now
22:29:07dom96any other ideas?
22:30:04Araqtry with --boundChecks:off etc. to see what check causes it
22:32:22dom96i'm already compiling with -d:release...
22:32:36Araqgah
22:38:51dom96well?
22:39:28Araqhmm
22:41:55fowlOrionPK, please try to compile nimlibs/examples/sdl_skeleton in OSX, try normal (dynamic link) and with -d:SDL_Static (static link) plz thank you!
22:42:04Araqtry to figure out which line causes it via --verbosity:3 and removing things in your main.nim file
22:42:44fowlim out for the day
22:42:54fowlsee yall later
22:42:58fowl(tomorrow)
22:43:15dom96Araq: ok
22:43:17dom96bye fowl
22:43:26Araqbye fowl
22:47:18dom96Removing the call to screenClear gets rid of the error
22:50:21Araqand the error is newObj, right?
23:00:31dom96yes
23:00:55dom96if I remove screenClear it becomes chckRange
23:01:15Araqdude
23:01:33Araqit's chckIndex then obviously
23:03:17dom96well dude, how was I suppose to know that?
23:04:40Araqwell I don't get it
23:04:47Araqyou said you compile with -d:release
23:04:54Araqwhy are the checks still active?
23:05:04dom96I have no idea
23:05:53reactormonkAraq, it's the same type of operation, just different for different data types - other option: error out when used with a string, telling to use the other one. Nah, not gonna happen.
23:06:40Araqreactormonk: use a 'when T is cstring' then within memcpy
23:07:01dom96Araq: and there is no such thing as a chckIndex
23:07:17reactormonkAraq, kk
23:07:36Araqdom96: excpt.chckIndx
23:09:58dom96and now it's back to newObj again
23:10:15dom96even with screenClear commented out
23:14:25Araqwell comment out the chck* procs
23:15:57dom96i just added them back lol
23:26:38*q66 quit (Quit: Leaving)