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:59 | leorize | shashlick: 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:32 | shashlick | I added -lc and that went away but then it complains about gcc symbols |
02:00:45 | shashlick | And -lgcc doesn't work |
02:01:13 | shashlick | Some mess of native vs cross compiler setup |
02:07:13 | * | banc quit (Quit: Bye) |
02:07:41 | leorize | use `-lgcc_s` |
02:07:49 | leorize | and yea, that's a cross compiling mess |
02:07:54 | leorize | how are you setting that up? |
02:32:01 | shashlick | Ya even -lgcc_s didn't work |
02:32:13 | shashlick | And the libgcc_s exists |
02:32:28 | shashlick | Using dockcross arm 6 image |
02:32:44 | shashlick | I 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:53 | leorize | I've never used docker :/ |
03:00:38 | leorize | what 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:14 | shashlick | Trying to build csources |
03:26:30 | shashlick | Nim bootstrap |
03:27:40 | shashlick | sh build.sh --cpu arm |
03:31:53 | FromGitter | <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:59 | FromGitter | <jrfondren> it's resisting, basically. Damn it. |
03:37:04 | leorize | shashlick: try exporting `LD=$CC` |
03:37:33 | leorize | that'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:04 | disruptek | jrfonden: why use regex? |
03:47:13 | disruptek | jrfondren: why use regex? |
03:48:13 | FromGitter | <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:35 | FromGitter | <jrfondren> since it doesn't, I can still get the job done by importing unicode and looping over str.runes() |
03:49:01 | disruptek | it's a utf-8? |
03:49:12 | FromGitter | <jrfondren> aye, UTF-8 |
03:49:20 | disruptek | i dunno why it doesn't work, do you? |
03:51:00 | shashlick | @leorize: here's the command line to start the container - docker run -t -i --rm -v `pwd`:/io dockcross/linux-armv6 bash |
03:51:14 | shashlick | then i just download nim and compile per usual |
03:53:57 | * | Snircle quit (Quit: Textual IRC Client: www.textualapp.com) |
03:55:02 | disruptek | the --rm will remove the container after you've done all that work to set it up. :-/ |
03:55:14 | disruptek | ie. as soon as you exit the shell. |
03:55:21 | shashlick | @leorize - $LD is set to /usr/bin/arm-linux-gnueabihf-ld and $CC is set to /usr/bin/arm-linux-gnueabihf-gcc |
03:56:41 | shashlick | @disruptek - good to know, i am not storing anything in it but ya |
03:58:48 | disruptek | docker is an amazing asset for the toolbox. truly a game-changer. |
04:06:40 | leorize | shashlick: please set it to CC |
04:07:11 | leorize | you'd want to use the compiler to link, which will add the needed lib automatically |
04:08:33 | shashlick | okay let me try |
04:10:32 | FromGitter | <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:47 | leorize | @jrfondren: use nim-regex and forget about pcre :p |
05:23:52 | shashlick | @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:15 | leorize | shashlick: 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:17 | leorize | [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:06 | Araq | lol… „The names derived class and base class were chosen because I |
07:36:06 | Araq | never could remember what was sub and what was super and observed that I was not the only one |
07:36:06 | Araq | with this particular problem.“ |
07:36:39 | Araq | Stroustrup had the same problem as me |
07:40:40 | Araq | leorize: really? that's sad. What should we remove? |
07:44:54 | FromGitter | <yglukhov> compilation to obj-c |
07:46:09 | * | salewski joined #nim |
07:47:46 | salewski | Araq, concerning our last forum discussion about suppress destroy, I wonder |
07:48:21 | salewski | if gc_ref() will be available at all for newruntime with owned refs. |
07:48:33 | salewski | I guess yes? |
07:50:07 | salewski | I guess gc_ref() will suppress dallocation, and gc_unref with refcount = 0 with immediately deallocate? |
07:55:25 | Araq | there are no plans to keep gc_ref() |
07:56:11 | * | Trustable quit (Remote host closed the connection) |
07:56:17 | Araq | it already is underspecified how it works and is inconsistent between --gc:refc and --gc:markAndSweep |
07:56:39 | Araq | and 'sink' is for parameters, not for variables. |
07:57:26 | salewski | Then I would suppose that I can emulate gc_ref() by putting the object in a hash set, |
07:57:45 | salewski | and gc_unref() by removing it from the hash set? |
07:58:48 | FromGitter | <yglukhov> 1) counted set |
07:58:51 | leorize | only if the hash set own the object I believe |
08:01:15 | Araq | salewski: my gut feeling is that you don't need it if you setup '=sink', '=', '=destroy' properly |
08:01:36 | Araq | nor do you need 'owned ref' for interfacing with C |
08:01:50 | Araq | but I gotta go, Happy Easter! |
08:02:02 | salewski | Araq, from your RFC: sink T is also a valid type for locals. For a variable |
08:02:21 | salewski | From https://github.com/nim-lang/Nim/wiki/Destructors |
08:04:57 | salewski | The problem with gtk is: I put a widget in a concainer, and get it back later from gtk. |
08:05:20 | salewski | Between these two actions I have no refering Nim object alive. |
08:05:38 | salewski | That is currently solved by gc_ref(). |
08:06:28 | salewski | Works fine for widgests. But at the same time this behaviour generated delayed |
08:07:04 | salewski | deaalocation, which can be bad for cairo objects like surfaces, which comsume very large memory chunks. |
08:07:36 | salewski | But OK, this has no big priority, current gtk/gintro implementation works not bad. |
08:07:40 | salewski | Bye. |
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:57 | FromGitter | <jrfondren> @leorize nim-regex is 13x slower than re, but I'll keep it in mind if it handles unicode well |
08:24:46 | leorize | @jrfondren: use the `--dynlibOverride:pcre` and `-l:-flags-to-link-to-prefered-pcre` combination to link to your unicode-enabled pcre |
08:25:16 | FromGitter | <jrfondren> ah, cool |
08:34:39 | * | ng0 joined #nim |
08:36:46 | FromGitter | <dom96> @yglukhov you want to remove compilation to obj_c? |
08:39:14 | FromGitter | <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:22 | FromGitter | <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:04 | dom96 | salewski: you would usually solve this by wrapping the GTK objects inside of a `ref` |
09:25:17 | dom96 | and deallocate those GTK objects when the finalize proc is called |
09:25:36 | dom96 | it would take a lot of wrapping but would have a chance of making GTK really nice in Nim |
09:28:35 | FromGitter | <mratsim> afaik that was what he was using before but he wanted to use destructors to optimise this instead |
09:29:23 | FromGitter | <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:11 | Araq | you can do proc `=`(...) {.error.} and then it's enforced it's moved around |
09:32:22 | dom96 | Araq, did you remove ospaths completely without a deprecation path? |
09:32:50 | Araq | no, it's in lib/deprecated/ospaths |
09:33:22 | Araq | *lib/deprecated/pure and that's in your default nim.cfg |
09:33:22 | dom96 | Oka, so this can be delayed https://github.com/nimble-test/issue280and524/pull/1 |
09:34:15 | Araq | sure but maybe something else doesn't work well |
09:34:26 | Araq | maybe lib/deprecated is not in Nimble's --path? |
09:34:45 | dom96 | meh, yeah. |
09:36:26 | FromGitter | <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:23 | Araq | mratsim: we should produce nice error messages before we close these issues |
09:49:17 | Araq | btw I'm reading this, http://www.stroustrup.com/hopl2.pdf very interesting. |
09:49:34 | Araq | C++ started out as "simple" too :P |
09:49:54 | Araq | and it had "call" and "return" functions. |
10:07:01 | * | iLiquid joined #nim |
10:07:48 | * | hoijui quit (Ping timeout: 252 seconds) |
10:24:33 | FromGitter | <gogolxdong> How come nimble install nimx doesn't install nimx files in nimble default Windows path? |
10:30:24 | FromGitter | <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:20 | FromGitter | <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:45 | salewski | dom96, indeed as mratsim just told you, gintro does all that wrapping well already. |
11:56:22 | salewski | And mratsim, copy is not the problem when we would use value objects and |
11:57:05 | salewski | destructors for that wrapping, as we can define our own ops for assignment and |
11:58:06 | salewski | equality test and so. Problen is only getParent(), getChild and such. When we get back |
11:59:04 | salewski | a gtk-widget from gtk and want a label or button. This works well with current refs. |
11:59:38 | * | jjido joined #nim |
11:59:57 | salewski | We can even extend widgets, for example attach additional fields to a button, put |
12:01:04 | salewski | it into a table or grid, get it back and access the added fields. |
12:01:10 | salewski | So I think I will let it as it is for now. Problem is only high performance cairo |
12:01:44 | salewski | drawing -- not many peole will do that, and when necessary they can add manually free/destroy. |
12:01:48 | salewski | Bye. |
12:03:45 | * | salewski quit (Quit: WeeChat 2.3) |
12:03:50 | FromGitter | <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:27 | FromGitter | <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:47 | FromGitter | <kaushalmodi> shashlick: are you here? |
13:02:28 | FromGitter | <kaushalmodi> are you aware of "number 7 insertion" related to nimterop |
13:02:34 | FromGitter | <kaushalmodi> here's what I mean: ⏎ ⏎ > CC: *7*7_7_7_7_7_7_7home7kmodi7.nimble7pkgs7nimterop-#head7nimterop7plugin |
13:03:10 | FromGitter | <kaushalmodi> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5cbc6a0e4b4cb471d9325a3c] |
13:03:24 | shashlick | I think that's something in Nim itself |
13:03:39 | FromGitter | <kaushalmodi> I'm not sure if I saw that before |
13:03:55 | FromGitter | <kaushalmodi> (I shouldn't have updated my Nim devel build :P) |
13:04:31 | FromGitter | <kaushalmodi> seems like forward slashes are replaced with number 7? |
13:04:35 | FromGitter | <kaushalmodi> but why? |
13:06:33 | FromGitter | <kaushalmodi> I happen to have an old terminal with earlier nimterop based proj compilation history |
13:06:41 | FromGitter | <kaushalmodi> there it just shows: ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5cbc6ae15b3f941aa569e1a8] |
13:07:34 | shashlick | https://github.com/nim-lang/Nim/commit/0121dda9ba903b764cbd234667cc03f79ebadf44 |
13:08:18 | FromGitter | <kaushalmodi> huh, yeah: https://github.com/nim-lang/Nim/commit/0121dda9ba903b764cbd234667cc03f79ebadf44#diff-90f103874d0c87ded9adfb75301b313eR41 |
13:08:19 | FromGitter | <kaushalmodi> thanks |
13:08:27 | FromGitter | <jrfondren> caused by https://github.com/nim-lang/Nim/commit/0121dda9ba903b764cbd234667cc03f79ebadf44 |
13:08:59 | FromGitter | <kaushalmodi> so nimterop_plugin and nimterop_cimport are "fake packages"> |
13:09:00 | FromGitter | <kaushalmodi> ? |
13:10:13 | shashlick | No idea |
13:10:15 | FromGitter | <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:41 | shashlick | Araq will know best |
13:11:44 | dom96 | lol beautiful fix |
13:12:13 | FromGitter | <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:46 | FromGitter | <kaushalmodi> yeah, I could reverse engineer what those 7's mean .. but it's definitely eye-widening |
13:13:16 | FromGitter | <kaushalmodi> may be we can continue discussion regarding this here: https://github.com/nim-lang/Nim/pull/11064#issuecomment-485250634 |
13:15:30 | shashlick | @jrfondren did you compare Nim-regex in release in mode |
13:16:22 | shashlick | C libs will be faster in debug mode since there's no Nim checks |
13:17:52 | FromGitter | <jrfondren> aye, -d:release --opt:speed. it's /^(?:\S+ ){3,4}<= ([^@]+@(\S+))/ against 400MB of exim logs. |
13:21:28 | FromGitter | <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:03 | shashlick | Ok cause I had a similar experience with Nim vs pure C hashing some time back |
13:45:09 | * | NimBot joined #nim |
14:07:18 | federico3 | does --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:52 | FromGitter | <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:56 | leorize | the 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:24 | FromGitter | <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:44 | leorize | yea, that's a tricky part |
15:32:51 | leorize | however, even if it works I doubt that it could produce the result you want |
15:34:26 | leorize | this is because the `let` symbol doesn't have any pragma attached to it |
15:36:14 | FromGitter | <deech> leorize: In that case is this a bug? Shouldn't assignment propagate pragmas? |
15:37:09 | FromGitter | <Araq> nah that's crazy talk |
15:37:53 | Araq | pragmas 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:02 | FromGitter | <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:07 | FromGitter | <arnetheduck> Araq, so `int` is a range-checked/bounded type and `uint` is a wrap-around type.. is that the intended semantic? |
15:56:55 | Araq | yes |
15:58:11 | FromGitter | <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:03 | Araq | I guess. |
15:59:06 | FromGitter | <arnetheduck> also, what's the rationale behind letting the backend ever see generic types? why not make them concrete in sem? |
15:59:53 | Araq | C++ interop pretty much requires it, you can import 'vector' from C++ |
16:04:04 | FromGitter | <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:14 | FromGitter | <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:22 | Araq | deprecate. or move it unittest.nim ? |
16:27:06 | * | jjido joined #nim |
16:29:27 | FromGitter | <arnetheduck> well, unittest can get its own global.. it's more whether it should keep existing in 0.20 or not.. |
16:31:03 | FromGitter | <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:47 | FromGitter | <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:08 | FromGitter | <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:18 | FromGitter | <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:25 | Araq | arnetheduck: " should nim itself be able to return an integer in any other way than `quit`" -- No. |
18:27:15 | Zevv | you 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:58 | FromGitter | <syhpoon> thanks @liquid600pgm ! I'll give it a shot |
19:03:04 | FromGitter | <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:32 | dom96 | arnetheduck: why don't you ping zah? He wrote it originally |
19:15:02 | FromGitter | <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:50 | shashlick | Is there any objection to adding few more release types to nightlies? |
19:51:25 | shashlick | Thinking arm variants, android, etc |
19:51:46 | shashlick | Should be easy with dockcross |
19:51:49 | shashlick | https://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:19 | FromDiscord | <exelotl> Hey, I was wondering if anyone might be able to help with a makefile problem I'm having? |
20:16:58 | FromDiscord | <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:02 | FromDiscord | <exelotl> https://github.com/exelotl/nim-tonc/tree/master/examples/hello_world |
20:18:50 | FromDiscord | <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:36 | FromDiscord | <exelotl> so I modified the makefile so that it runs nim on line 122 |
20:20:42 | FromDiscord | <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:40 | FromDiscord | <exelotl> cause it doesn't know that the C files produced by Nim exist yet |
20:26:58 | disruptek | exelotl: teach your make how to build .c files from .nim files. |
20:31:22 | FromDiscord | <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:40 | FromDiscord | <exelotl> but in this case, many .c files come from just main.nim |
20:32:06 | FromDiscord | <exelotl> so what kind of rule do I need here? |
20:36:12 | * | hoijui joined #nim |
20:40:02 | Zevv | you can make the rules explicit: |
20:40:12 | Zevv | foo.c bar.c bizz.c buzz.c: main.nim |
20:41:03 | Zevv | nim c main.nim |
20:41:39 | * | hoijui quit (Ping timeout: 250 seconds) |
20:56:38 | FromDiscord | <exelotl> but I don't know how many or what are the names of all the C files that nim will output |
20:57:54 | Zevv | make a rule that compiles your nim code as a dependency of your end target |
20:58:11 | Zevv | and use $(wildcard *.c) to compile the c files after that |
20:59:48 | FromDiscord | <!!Liam is Unlucky> how many bits in the default int |
21:00:00 | FromDiscord | <exelotl> @!!Liam is Unlucky |
21:00:03 | FromDiscord | <exelotl> oops |
21:00:24 | FromDiscord | <exelotl> I was gonna say it depends on your compiler / platform |
21:00:45 | FromDiscord | <!!Liam is Unlucky> oh ok thanks, |
21:01:02 | Zevv | roughly somewhere between 16 and 64 |
21:01:23 | FromDiscord | <!!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:49 | Zevv | not always, that might result in sub-optimal code |
21:02:03 | FromDiscord | <exelotl> yeah you should prefer int wherever the number of bits doesn't matter |
21:02:13 | FromDiscord | <!!Liam is Unlucky> yeah ok thanks |
21:03:13 | FromDiscord | <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:48 | FromDiscord | <exelotl> but then it's guaranteed to be a 32 bit architecture so I think it's ok to make that assumption |
21:16:19 | disruptek | use `int32` when you know it needs to be 32-bit. `12345'i32` is the literal integer 12345 in an int32. |
21:33:22 | FromDiscord | <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:14 | FromDiscord | <exelotl> if the native int size is not 32 bits in my project then something is deeply wrong already |
21:35:24 | FromDiscord | <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:30 | disruptek | uints 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:15 | FromDiscord | <!!Liam is Unlucky> is ptr the same as pointer |
22:24:58 | FromDiscord | <!!Liam is Unlucky> k nvm I think it it |
22:27:13 | * | [rg] quit (Quit: Leaving) |
22:27:37 | FromGitter | <kaushalmodi> I think that ptr is used to make a typed pointer |
22:27:53 | FromGitter | <kaushalmodi> `pointer` vs something like `ptr cint` |
22:29:25 | FromDiscord | <!!Liam is Unlucky> oh ok |
23:11:38 | * | rnrwashere quit (Remote host closed the connection) |
23:13:36 | disruptek | i have some kinda weird bug with exception handling; different behavior between `nim c`, `nim cpp`, and `nim cpp --noCppExceptions`. sound familiar? |
23:18:09 | disruptek | i 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 |