<< 21-04-2019 >>

00:22:48*rnrwashere joined #nim
00:24:58*rnrwashere quit (Remote host closed the connection)
01:04:08*Cthalupa quit (Ping timeout: 268 seconds)
01:04:57*Cthalupa joined #nim
01:19:12*abm quit (Quit: Leaving)
01:27:59leorizeshashlick: that's weird. it means that your libc doesn't use symbol versioning but gcc tries to use them anyway
01:28:17*Snircle is now known as Jack_
01:29:18*Jack_ is now known as Snircle
01:48:32*ng0 quit (Quit: Alexa, when is the end of world?)
02:00:32shashlickI added -lc and that went away but then it complains about gcc symbols
02:00:45shashlickAnd -lgcc doesn't work
02:01:13shashlickSome mess of native vs cross compiler setup
02:07:13*banc quit (Quit: Bye)
02:07:41leorizeuse `-lgcc_s`
02:07:49leorizeand yea, that's a cross compiling mess
02:07:54leorizehow are you setting that up?
02:32:01shashlickYa even -lgcc_s didn't work
02:32:13shashlickAnd the libgcc_s exists
02:32:28shashlickUsing dockcross arm 6 image
02:32:44shashlickI tried arm7 too but same issue there
02:33:22*banc joined #nim
02:38:12*[rg] joined #nim
02:47:11*zestyr joined #nim
02:59:53leorizeI've never used docker :/
03:00:38leorizewhat are you building with it? and how?
03:05:02*Cthalupa quit (Ping timeout: 246 seconds)
03:07:09*Cthalupa joined #nim
03:19:21*dddddd quit (Remote host closed the connection)
03:26:14shashlickTrying to build csources
03:26:30shashlickNim bootstrap
03:27:40shashlicksh build.sh --cpu arm
03:31:53FromGitter<jrfondren> 1) discover the penultimate evil of unicode ("pretty" quotes) in some data ⏎ 2) use unidecode to deal with that. GJ ⏎ 3) write a tool in nim to help find more penultimate evil of unicode: evilgrep ⏎ 4) tool works by checking for line != unidecode(line) and works great ⏎ 5) improve tool! it should highlight the evil with terminal colors ... [https://gitter.im/nim-lang/Nim?at=5cbbe429375bac7470dba628]
03:32:59FromGitter<jrfondren> it's resisting, basically. Damn it.
03:37:04leorizeshashlick: try exporting `LD=$CC`
03:37:33leorizethat's how you do it on Linux if you wanted to use a different compiler
03:42:58*vlad1777d joined #nim
03:44:42*arecacea1 quit (Remote host closed the connection)
03:45:06*arecacea1 joined #nim
03:47:04disruptekjrfonden: why use regex?
03:47:13disruptekjrfondren: why use regex?
03:48:13FromGitter<jrfondren> I assumed it'd work and I wanted to use lookaheads and lookbehinds to slide color codes around non-ASCII characters in a string
03:48:35FromGitter<jrfondren> since it doesn't, I can still get the job done by importing unicode and looping over str.runes()
03:49:01disruptekit's a utf-8?
03:49:12FromGitter<jrfondren> aye, UTF-8
03:49:20disrupteki dunno why it doesn't work, do you?
03:51:00shashlick@leorize: here's the command line to start the container - docker run -t -i --rm -v `pwd`:/io dockcross/linux-armv6 bash
03:51:14shashlickthen i just download nim and compile per usual
03:53:57*Snircle quit (Quit: Textual IRC Client: www.textualapp.com)
03:55:02disruptekthe --rm will remove the container after you've done all that work to set it up. :-/
03:55:14disruptekie. as soon as you exit the shell.
03:55:21shashlick@leorize - $LD is set to /usr/bin/arm-linux-gnueabihf-ld and $CC is set to /usr/bin/arm-linux-gnueabihf-gcc
03:56:41shashlick@disruptek - good to know, i am not storing anything in it but ya
03:58:48disruptekdocker is an amazing asset for the toolbox. truly a game-changer.
04:06:40leorizeshashlick: please set it to CC
04:07:11leorizeyou'd want to use the compiler to link, which will add the needed lib automatically
04:08:33shashlickokay let me try
04:10:32FromGitter<jrfondren> PCRE (before v2) doesn't support unicode by default. there's a compile-time flag and a API flag. Nim doesn't use the API flag, but when I try adding it I'm getting errors from libpcre that the flag bit's invalid, so at a guess Nim's linking to the macOS system pcre (who even knows how that's set up) instead of the homebrew pcre (which definitely has UTF8 enabled)
04:26:01*rnrwashere joined #nim
04:30:31*rnrwashere quit (Ping timeout: 264 seconds)
05:17:47leorize@jrfondren: use nim-regex and forget about pcre :p
05:23:52shashlick@leorize - LC=$CC worked!
05:55:27[rg]whats the best project to try a lot of nim features for a new commer?
06:00:58*Jjp137 quit (Read error: Connection reset by peer)
06:01:36*Jjp137 joined #nim
06:02:15leorizeshashlick: this is because bootstrap used the wrong variable. If the C compiler is wanted for linking, the CCLD variable should be used instead.
06:05:17leorize[rg]: Nim has so many features that I don't think you can make a project that use most of them :p
06:13:34[rg]well I ask since, im pretty comfortable with learning new languages, just wondering what the defining feature of nim is?
06:13:41[rg]like how go has goroutines
06:29:52*solitudesf joined #nim
06:42:05*[rg] quit (Quit: Leaving)
06:44:15*nsf joined #nim
07:00:00*gmpreussner quit (Quit: kthxbye)
07:04:37*gmpreussner joined #nim
07:07:13*kapil____ joined #nim
07:26:20*Trustable joined #nim
07:26:46*jjido joined #nim
07:36:06Araqlol… „The names derived class and base class were chosen because I
07:36:06Araqnever could remember what was sub and what was super and observed that I was not the only one
07:36:06Araqwith this particular problem.“
07:36:39AraqStroustrup had the same problem as me
07:40:40Araqleorize: really? that's sad. What should we remove?
07:44:54FromGitter<yglukhov> compilation to obj-c
07:46:09*salewski joined #nim
07:47:46salewskiAraq, concerning our last forum discussion about suppress destroy, I wonder
07:48:21salewskiif gc_ref() will be available at all for newruntime with owned refs.
07:48:33salewskiI guess yes?
07:50:07salewskiI guess gc_ref() will suppress dallocation, and gc_unref with refcount = 0 with immediately deallocate?
07:55:25Araqthere are no plans to keep gc_ref()
07:56:11*Trustable quit (Remote host closed the connection)
07:56:17Araqit already is underspecified how it works and is inconsistent between --gc:refc and --gc:markAndSweep
07:56:39Araqand 'sink' is for parameters, not for variables.
07:57:26salewskiThen I would suppose that I can emulate gc_ref() by putting the object in a hash set,
07:57:45salewskiand gc_unref() by removing it from the hash set?
07:58:48FromGitter<yglukhov> 1) counted set
07:58:51leorizeonly if the hash set own the object I believe
08:01:15Araqsalewski: my gut feeling is that you don't need it if you setup '=sink', '=', '=destroy' properly
08:01:36Araqnor do you need 'owned ref' for interfacing with C
08:01:50Araqbut I gotta go, Happy Easter!
08:02:02salewskiAraq, from your RFC: sink T is also a valid type for locals. For a variable
08:02:21salewskiFrom https://github.com/nim-lang/Nim/wiki/Destructors
08:04:57salewskiThe problem with gtk is: I put a widget in a concainer, and get it back later from gtk.
08:05:20salewskiBetween these two actions I have no refering Nim object alive.
08:05:38salewskiThat is currently solved by gc_ref().
08:06:28salewskiWorks fine for widgests. But at the same time this behaviour generated delayed
08:07:04salewskideaalocation, which can be bad for cairo objects like surfaces, which comsume very large memory chunks.
08:07:36salewskiBut OK, this has no big priority, current gtk/gintro implementation works not bad.
08:07:40salewskiBye.
08:07:47*solitudesf quit (Ping timeout: 268 seconds)
08:08:09*salewski quit (Quit: WeeChat 2.3)
08:14:34*hoijui joined #nim
08:17:57FromGitter<jrfondren> @leorize nim-regex is 13x slower than re, but I'll keep it in mind if it handles unicode well
08:24:46leorize@jrfondren: use the `--dynlibOverride:pcre` and `-l:-flags-to-link-to-prefered-pcre` combination to link to your unicode-enabled pcre
08:25:16FromGitter<jrfondren> ah, cool
08:34:39*ng0 joined #nim
08:36:46FromGitter<dom96> @yglukhov you want to remove compilation to obj_c?
08:39:14FromGitter<jrfondren> ... crazy, that same benchmark with npeg is only 1.3x slower than PCRE. Took me a lot longer to get the match right, and I had to remove left recursion from what I was doing.
08:39:22FromGitter<jrfondren> ls
08:54:50*Cthalupa quit (Ping timeout: 244 seconds)
08:57:45*Cthalupa joined #nim
09:00:47*ng0 quit (Quit: Alexa, when is the end of world?)
09:25:04dom96salewski: you would usually solve this by wrapping the GTK objects inside of a `ref`
09:25:17dom96and deallocate those GTK objects when the finalize proc is called
09:25:36dom96it would take a lot of wrapping but would have a chance of making GTK really nice in Nim
09:28:35FromGitter<mratsim> afaik that was what he was using before but he wanted to use destructors to optimise this instead
09:29:23FromGitter<mratsim> but as I said in the forum, destructors are in my opinion only suitable trivial types, if you cannot trivially copy a type you should use ref instead
09:31:11Araqyou can do proc `=`(...) {.error.} and then it's enforced it's moved around
09:32:22dom96Araq, did you remove ospaths completely without a deprecation path?
09:32:50Araqno, it's in lib/deprecated/ospaths
09:33:22Araq*lib/deprecated/pure and that's in your default nim.cfg
09:33:22dom96Oka, so this can be delayed https://github.com/nimble-test/issue280and524/pull/1
09:34:15Araqsure but maybe something else doesn't work well
09:34:26Araqmaybe lib/deprecated is not in Nimble's --path?
09:34:45dom96meh, yeah.
09:36:26FromGitter<mratsim> @Araq, should we close this? https://github.com/nim-lang/Nim/issues/9731, a good start to remove type parameters is here, it's celebrating its first brthday: https://github.com/nim-lang/Nim/pull/7681
09:47:23Araqmratsim: we should produce nice error messages before we close these issues
09:49:17Araqbtw I'm reading this, http://www.stroustrup.com/hopl2.pdf very interesting.
09:49:34AraqC++ started out as "simple" too :P
09:49:54Araqand it had "call" and "return" functions.
10:07:01*iLiquid joined #nim
10:07:48*hoijui quit (Ping timeout: 252 seconds)
10:24:33FromGitter<gogolxdong> How come nimble install nimx doesn't install nimx files in nimble default Windows path?
10:30:24FromGitter<gogolxdong> After copying to default path, got`cannot open file: nimx/window`
11:06:19*luis_ joined #nim
11:11:02*Snircle joined #nim
11:43:33*jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
11:44:20FromGitter<mratsim> probably because there is no nimx.nim in nimx and nimble is confused
11:45:37*luis_ quit (Ping timeout: 246 seconds)
11:53:43*salewski joined #nim
11:55:45salewskidom96, indeed as mratsim just told you, gintro does all that wrapping well already.
11:56:22salewskiAnd mratsim, copy is not the problem when we would use value objects and
11:57:05salewskidestructors for that wrapping, as we can define our own ops for assignment and
11:58:06salewskiequality test and so. Problen is only getParent(), getChild and such. When we get back
11:59:04salewskia gtk-widget from gtk and want a label or button. This works well with current refs.
11:59:38*jjido joined #nim
11:59:57salewskiWe can even extend widgets, for example attach additional fields to a button, put
12:01:04salewskiit into a table or grid, get it back and access the added fields.
12:01:10salewskiSo I think I will let it as it is for now. Problem is only high performance cairo
12:01:44salewskidrawing -- not many peole will do that, and when necessary they can add manually free/destroy.
12:01:48salewskiBye.
12:03:45*salewski quit (Quit: WeeChat 2.3)
12:03:50FromGitter<yglukhov> @dom96 yeah, i think obj-c "support" is (a) not well-thought and (b) can be implemented better in a library. https://github.com/yglukhov/darwin
12:05:27FromGitter<yglukhov> ok, "not well-thought" is a wrong definition of current obj-c support, but it definitely has some flaws
12:26:32*rnrwashere joined #nim
12:30:58*rnrwashere quit (Ping timeout: 258 seconds)
12:34:09*lritter joined #nim
12:42:09*iLiquid quit (Quit: iLiquid)
12:42:19*iLiquid joined #nim
12:45:54*arecacea1 quit (Remote host closed the connection)
12:46:32*arecacea1 joined #nim
12:47:25*dddddd joined #nim
13:01:47FromGitter<kaushalmodi> shashlick: are you here?
13:02:28FromGitter<kaushalmodi> are you aware of "number 7 insertion" related to nimterop
13:02:34FromGitter<kaushalmodi> here's what I mean: ⏎ ⏎ > CC: *7*7_7_7_7_7_7_7home7kmodi7.nimble7pkgs7nimterop-#head7nimterop7plugin
13:03:10FromGitter<kaushalmodi> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5cbc6a0e4b4cb471d9325a3c]
13:03:24shashlickI think that's something in Nim itself
13:03:39FromGitter<kaushalmodi> I'm not sure if I saw that before
13:03:55FromGitter<kaushalmodi> (I shouldn't have updated my Nim devel build :P)
13:04:31FromGitter<kaushalmodi> seems like forward slashes are replaced with number 7?
13:04:35FromGitter<kaushalmodi> but why?
13:06:33FromGitter<kaushalmodi> I happen to have an old terminal with earlier nimterop based proj compilation history
13:06:41FromGitter<kaushalmodi> there it just shows: ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5cbc6ae15b3f941aa569e1a8]
13:07:34shashlickhttps://github.com/nim-lang/Nim/commit/0121dda9ba903b764cbd234667cc03f79ebadf44
13:08:18FromGitter<kaushalmodi> huh, yeah: https://github.com/nim-lang/Nim/commit/0121dda9ba903b764cbd234667cc03f79ebadf44#diff-90f103874d0c87ded9adfb75301b313eR41
13:08:19FromGitter<kaushalmodi> thanks
13:08:27FromGitter<jrfondren> caused by https://github.com/nim-lang/Nim/commit/0121dda9ba903b764cbd234667cc03f79ebadf44
13:08:59FromGitter<kaushalmodi> so nimterop_plugin and nimterop_cimport are "fake packages">
13:09:00FromGitter<kaushalmodi> ?
13:10:13shashlickNo idea
13:10:15FromGitter<jrfondren> that's a fix for the "multiple utils" thing discussed a few days ago. I guess nimble does some introspection and it's seeing these packages
13:10:41shashlickAraq will know best
13:11:44dom96lol beautiful fix
13:12:13FromGitter<jrfondren> if you discount the 7 that's part of /home, there are seven 7s prior to the path to your module. I hope this improves your view of the aesthetics of that output.
13:12:46FromGitter<kaushalmodi> yeah, I could reverse engineer what those 7's mean .. but it's definitely eye-widening
13:13:16FromGitter<kaushalmodi> may be we can continue discussion regarding this here: https://github.com/nim-lang/Nim/pull/11064#issuecomment-485250634
13:15:30shashlick@jrfondren did you compare Nim-regex in release in mode
13:16:22shashlickC libs will be faster in debug mode since there's no Nim checks
13:17:52FromGitter<jrfondren> aye, -d:release --opt:speed. it's /^(?:\S+ ){3,4}<= ([^@]+@(\S+))/ against 400MB of exim logs.
13:21:28FromGitter<jrfondren> if regex does better in your experience, it might be that some feature of that regex is performing poorly. I've run into some cases like that with other tests. Python doesn't like \b , f.e.
13:27:03shashlickOk cause I had a similar experience with Nim vs pure C hashing some time back
13:45:09*NimBot joined #nim
14:07:18federico3does --git.tag work for repositories other than GitHub?
14:18:47*iLiquid quit (Quit: iLiquid)
14:31:14*redlegion quit (Quit: Ded.)
14:38:15*redlegion joined #nim
14:38:16*redlegion quit (Changing host)
14:38:16*redlegion joined #nim
14:41:16*solitudesf joined #nim
14:47:21*luis_ joined #nim
15:06:47*rnrwashere joined #nim
15:08:23*i7sDream quit (Ping timeout: 245 seconds)
15:20:52FromGitter<deech> Why does the following fail with the compiler error `node is not a symbol` on the assert line: ⏎ ⏎ ```assert (foo.hasCustomPragma(p))``` [https://gitter.im/nim-lang/Nim?at=5cbc8a54b489bb6ed79f031f]
15:26:56leorizethe pragma `pragma` is used to create custom pragma based on existing ones. You don't have to annotate your template with it to create a custom pragma
15:28:24FromGitter<deech> leorize: I see, thanks! I was following the manual but I still don't see why the latter works and the former does not.
15:32:39*SenasOzys joined #nim
15:32:44leorizeyea, that's a tricky part
15:32:51leorizehowever, even if it works I doubt that it could produce the result you want
15:34:26leorizethis is because the `let` symbol doesn't have any pragma attached to it
15:36:14FromGitter<deech> leorize: In that case is this a bug? Shouldn't assignment propagate pragmas?
15:37:09FromGitter<Araq> nah that's crazy talk
15:37:53Araqpragmas are not values, they are not propagated
15:38:56*iLiquid joined #nim
15:40:56*Cthalupa quit (Ping timeout: 255 seconds)
15:41:42*Cthalupa joined #nim
15:45:12*luis_ quit (Ping timeout: 250 seconds)
15:50:02FromGitter<syhpoon> Hey guys, I'm struggling with some particular use of generics and type classes, which doesn't compile: ⏎ ⏎ ```code paste, see link``` ⏎ ⏎ This has something to do with type union `Request[P] = Request1[P] | Request2[P]` if I understand correctly but I don't have enough Nim experience yet to be able to figure this out myself :( [https://gitter.im/nim-lang/Nim?at=5cbc912ab489bb6ed79f2f83]
15:54:07FromGitter<arnetheduck> Araq, so `int` is a range-checked/bounded type and `uint` is a wrap-around type.. is that the intended semantic?
15:56:55Araqyes
15:58:11FromGitter<arnetheduck> so would it make sense that it's the `sem` part of the compiler that ensures that no `nkChckRange` for `uint` make it to the backend?
15:59:03AraqI guess.
15:59:06FromGitter<arnetheduck> also, what's the rationale behind letting the backend ever see generic types? why not make them concrete in sem?
15:59:53AraqC++ interop pretty much requires it, you can import 'vector' from C++
16:04:04FromGitter<arnetheduck> hm, right. and I would guess it's a bug when types in the ast don't match (for example different integer sizes or whatever), but the c backend plasters over it with liberal casting?
16:05:14FromGitter<arnetheduck> re nim_program_result, just remove or deprecate?
16:18:02*hoijui joined #nim
16:20:47*jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
16:26:22Araqdeprecate. or move it unittest.nim ?
16:27:06*jjido joined #nim
16:29:27FromGitter<arnetheduck> well, unittest can get its own global.. it's more whether it should keep existing in 0.20 or not..
16:31:03FromGitter<arnetheduck> in playing around with wasm, it's quite reasonable to start with `os:standalone` as starting point - it's a bit annoying that there's nim cruft lying around then, like program_result (and a few other things, but those are not exported at least, so they get collected)
16:32:47FromGitter<arnetheduck> the question then is, should nim itself be able to return an integer in any other way than `quit`.. ie if you look at how glibc for example is done, it effectively calls `quit(main(...))` from the real system entry point
16:34:08FromGitter<arnetheduck> the whole quit(int) business is kind of an operating system / process convention, but it doesn't quite add up in cases outside of that
16:47:32*jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
16:56:59*[rg] joined #nim
17:19:00*SenasOzys quit (Read error: Connection reset by peer)
17:19:56*rnrwashere quit (Remote host closed the connection)
17:41:34*fanta1 joined #nim
17:50:18FromGitter<liquid600pgm> @syhpoon `Request` is not a concrete type, so you cannot use it as a field in tuples and objects. You'll have to use inheritance here, creating a `type BaseRequest[P] = ref object of RootObj`, and then inheriting your other requests from it: `type Request1[P] = ref object of BaseRequest[P]`. Then you'll be able to use `Request[P]` as a field
18:24:25Araqarnetheduck: " should nim itself be able to return an integer in any other way than `quit`" -- No.
18:27:15Zevvyou can return 1 by raising an exception :)
18:28:29*natrys joined #nim
18:36:16*fanta1 quit (Quit: fanta1)
18:57:55*stefanos82 joined #nim
18:59:58FromGitter<syhpoon> thanks @liquid600pgm ! I'll give it a shot
19:03:04FromGitter<arnetheduck> Araq, ok, unittest was more annoying than I thought.. it imperatively runs tests thus there's no way to hook into "all tests ended".. sigh.. `addQuitProc` otoh calls `at_exit` - from inside there, you're not allowed to call `exit` again, or `longjmp` (aka `raise`)..
19:08:32dom96arnetheduck: why don't you ping zah? He wrote it originally
19:15:02FromGitter<arnetheduck> he also added the variable initially it seems
19:20:08*shomodj joined #nim
19:21:33*kapil____ quit (Quit: Connection closed for inactivity)
19:23:14*nsf quit (Quit: WeeChat 2.4)
19:33:55*shomodj quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
19:37:52*shomodj joined #nim
19:46:19*arecacea1 quit (Remote host closed the connection)
19:46:39*arecacea1 joined #nim
19:49:57*shomodj quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
19:50:50shashlickIs there any objection to adding few more release types to nightlies?
19:51:25shashlickThinking arm variants, android, etc
19:51:46shashlickShould be easy with dockcross
19:51:49shashlickhttps://github.com/dockcross/dockcross/blob/master/README.rst
19:53:50*abm joined #nim
19:54:40*cyraxjoe quit (Quit: No Ping reply in 180 seconds.)
19:55:57*cyraxjoe joined #nim
19:56:18*shomodj joined #nim
20:10:47*hoijui quit (Ping timeout: 240 seconds)
20:16:19FromDiscord<exelotl> Hey, I was wondering if anyone might be able to help with a makefile problem I'm having?
20:16:58FromDiscord<exelotl> basically I'm using Nim to produce C source files and then using some makefiles from an existing toolkit to produce the final binary
20:17:02FromDiscord<exelotl> https://github.com/exelotl/nim-tonc/tree/master/examples/hello_world
20:18:50FromDiscord<exelotl> it would be nice if I could just do `make` to build everything rather than having to do `nim c main.nim && make`
20:19:36FromDiscord<exelotl> so I modified the makefile so that it runs nim on line 122
20:20:42FromDiscord<exelotl> but the problem here is, the makefile has already set the CFILES variable so when you build the project for the first time, or any time you add a new source file, you will get undefined reference errors unless you run make twice
20:23:40FromDiscord<exelotl> cause it doesn't know that the C files produced by Nim exist yet
20:26:58disruptekexelotl: teach your make how to build .c files from .nim files.
20:31:22FromDiscord<exelotl> I'm kinda confused about that, since usually there's a rule like %.o: %.c to say "every .o file comes from a corresponding .c file"
20:31:40FromDiscord<exelotl> but in this case, many .c files come from just main.nim
20:32:06FromDiscord<exelotl> so what kind of rule do I need here?
20:36:12*hoijui joined #nim
20:40:02Zevvyou can make the rules explicit:
20:40:12Zevvfoo.c bar.c bizz.c buzz.c: main.nim
20:41:03Zevv nim c main.nim
20:41:39*hoijui quit (Ping timeout: 250 seconds)
20:56:38FromDiscord<exelotl> but I don't know how many or what are the names of all the C files that nim will output
20:57:54Zevvmake a rule that compiles your nim code as a dependency of your end target
20:58:11Zevvand use $(wildcard *.c) to compile the c files after that
20:59:48FromDiscord<!!Liam is Unlucky> how many bits in the default int
21:00:00FromDiscord<exelotl> @!!Liam is Unlucky
21:00:03FromDiscord<exelotl> oops
21:00:24FromDiscord<exelotl> I was gonna say it depends on your compiler / platform
21:00:45FromDiscord<!!Liam is Unlucky> oh ok thanks,
21:01:02Zevvroughly somewhere between 16 and 64
21:01:23FromDiscord<!!Liam is Unlucky> @exelotl is it better to specify which you want to use each time instead of just int, (int64, 32 etc)
21:01:49Zevvnot always, that might result in sub-optimal code
21:02:03FromDiscord<exelotl> yeah you should prefer int wherever the number of bits doesn't matter
21:02:13FromDiscord<!!Liam is Unlucky> yeah ok thanks
21:03:13FromDiscord<exelotl> I'm actually using int for convenience on the GBA even though it's very important that it should always be 32 bits... xD
21:03:48FromDiscord<exelotl> but then it's guaranteed to be a 32 bit architecture so I think it's ok to make that assumption
21:16:19disruptekuse `int32` when you know it needs to be 32-bit. `12345'i32` is the literal integer 12345 in an int32.
21:33:22FromDiscord<exelotl> the distinction between 'ints that absolutely must be 32-bit' and 'ints that should ideally be 32 bit' and 'regular ints' is kinda blurry and I'd rather not think about it
21:34:14FromDiscord<exelotl> if the native int size is not 32 bits in my project then something is deeply wrong already
21:35:24FromDiscord<exelotl> but if there's like a 32 bit I/O register or something then of course I'll use uint32 for that
21:36:30disruptekuints have different semantics.
21:38:14*dddddd quit (Ping timeout: 255 seconds)
21:38:29*solitudesf- joined #nim
21:39:40*solitudesf quit (Ping timeout: 250 seconds)
21:42:13*iLiquid quit (Quit: iLiquid)
21:48:48*solitudesf- quit (Ping timeout: 244 seconds)
21:48:51*stefanos82 quit (Remote host closed the connection)
21:51:48*dddddd joined #nim
22:05:45*shomodj quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
22:05:53*abm quit (Read error: Connection reset by peer)
22:06:19*Snircle quit (Quit: Textual IRC Client: www.textualapp.com)
22:06:27*abm joined #nim
22:16:11*rnrwashere joined #nim
22:21:12*natrys quit (Quit: natrys)
22:22:57*Snircle joined #nim
22:23:15FromDiscord<!!Liam is Unlucky> is ptr the same as pointer
22:24:58FromDiscord<!!Liam is Unlucky> k nvm I think it it
22:27:13*[rg] quit (Quit: Leaving)
22:27:37FromGitter<kaushalmodi> I think that ptr is used to make a typed pointer
22:27:53FromGitter<kaushalmodi> `pointer` vs something like `ptr cint`
22:29:25FromDiscord<!!Liam is Unlucky> oh ok
23:11:38*rnrwashere quit (Remote host closed the connection)
23:13:36disrupteki have some kinda weird bug with exception handling; different behavior between `nim c`, `nim cpp`, and `nim cpp --noCppExceptions`. sound familiar?
23:18:09disrupteki mean, i understand that the --noCppExceptions switch is there to alter the behavior, but i feel like i should see only two different behaviors at most, not three.
23:39:13*lritter quit (Ping timeout: 245 seconds)
23:49:22*[rg] joined #nim