| 00:01:15 | * | kulelu88 joined #nim |
| 00:03:13 | * | user0__ quit (Ping timeout: 260 seconds) |
| 00:20:02 | * | PMunch quit (Quit: leaving) |
| 00:21:05 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 00:22:22 | demi- | hmmm, i'm getting an decref exception when using `sequtils.filter` is there anything i should be aware of with this? |
| 00:24:22 | * | sz0 quit (Quit: Connection closed for inactivity) |
| 00:25:08 | * | kulelu88_ joined #nim |
| 00:26:24 | * | kulelu88 quit (Ping timeout: 240 seconds) |
| 00:29:24 | * | kulelu88_ quit (Ping timeout: 240 seconds) |
| 00:29:59 | demi- | hmmm, ok it looks like something is blowing up memory badly |
| 01:00:23 | demi- | ok by changing my GC method to `markAndSweep` i stop having the problem; but i don't think this is the proper solution here, is there anything i can do to debug this? |
| 01:01:12 | ftsf_ | demi-, not sure, but maybe tri keepIf instead of filter |
| 01:01:19 | ftsf_ | to do removal in place |
| 01:01:30 | demi- | i removed the filter call, and it was still happening |
| 01:01:41 | ftsf_ | well... problem is likely somewhere else then =) |
| 01:02:12 | ftsf_ | what's a decref exception? never encountered that |
| 01:02:30 | demi- | something is being trambled, but i don't know where/how and the usual tools i would use to debug this won't work because of nim's GC system over-top of C |
| 01:03:13 | ftsf_ | valgrind not helping? |
| 01:04:25 | demi- | the traceback looks like this: https://gist.github.com/samdmarshall/2a291d1b4b5a615ea655bdb9066265fc |
| 01:05:47 | demi- | that is one of them, it appears to be whenever nim goes to garbage collect when generating a new object it will throw |
| 01:06:29 | ftsf_ | did you run it through valgrind? |
| 01:06:52 | ftsf_ | if there's memory corruption earlier on that traceback won't be very useful |
| 01:07:44 | demi- | i wasn't aware that you could effectively use valgrind or llvm ASAN on nim code |
| 01:11:18 | ftsf_ | you can =) |
| 01:15:43 | * | couven92 quit (Quit: Good Night) |
| 01:23:00 | demi- | ASAN seems to break running the code altogether, and valgrind apparently doesn't support my platform |
| 01:42:04 | demi- | this is what ends up happening: https://gist.github.com/samdmarshall/ef875faea7b4a0bcaa3742dc97e043f1 |
| 02:15:06 | * | brson quit (Quit: leaving) |
| 02:20:07 | * | def-pri-pub quit (Read error: Connection reset by peer) |
| 02:20:16 | * | def-pri-pub joined #nim |
| 02:20:17 | * | def-pri-pub quit (Changing host) |
| 02:20:17 | * | def-pri-pub joined #nim |
| 02:30:05 | * | chemist69 quit (Ping timeout: 246 seconds) |
| 02:33:22 | * | chemist69 joined #nim |
| 02:33:46 | FromGitter | <Varriount> demi-: Are you using any modules not found in the standard library? |
| 02:34:52 | FromGitter | <Varriount> Or using threads? |
| 02:35:17 | FromGitter | <Varriount> It sounds like something is corrupting data, and the garbage collector doesn't like that/ |
| 02:37:55 | * | user0__ joined #nim |
| 02:37:55 | * | user0__ quit (Remote host closed the connection) |
| 02:38:08 | * | user0___ joined #nim |
| 02:39:58 | * | user0___ quit (Read error: Connection reset by peer) |
| 02:40:24 | * | user0___ joined #nim |
| 02:41:09 | * | CcxWrk quit (Ping timeout: 240 seconds) |
| 02:42:20 | * | CcxWrk joined #nim |
| 02:44:31 | * | user0___ quit (Read error: Connection reset by peer) |
| 02:45:08 | * | user0___ joined #nim |
| 02:59:36 | * | user0___ quit (Ping timeout: 240 seconds) |
| 03:01:00 | * | libman quit (Quit: Connection closed for inactivity) |
| 03:03:29 | * | chemist69 quit (Ping timeout: 240 seconds) |
| 03:17:16 | * | chemist69 joined #nim |
| 03:20:42 | * | girvo joined #nim |
| 03:33:36 | * | BitPuffin|osx quit (Ping timeout: 260 seconds) |
| 03:49:18 | * | rauss quit (Quit: WeeChat 1.7) |
| 03:50:19 | * | rauss joined #nim |
| 03:54:08 | * | Snircle quit (Quit: Textual IRC Client: www.textualapp.com) |
| 04:04:06 | * | def-pri-pub quit (Quit: leaving) |
| 04:08:42 | * | zachcarter joined #nim |
| 04:33:39 | * | pie_ joined #nim |
| 04:45:48 | * | deavmi__ joined #nim |
| 04:50:08 | * | deavmi__ quit (Client Quit) |
| 04:59:05 | * | arnetheduck joined #nim |
| 05:03:28 | * | user0___ joined #nim |
| 05:04:39 | * | chemist69 quit (Ping timeout: 258 seconds) |
| 05:09:13 | * | chemist69 joined #nim |
| 05:23:30 | * | pie_ quit (Quit: Leaving) |
| 05:35:35 | * | Vladar joined #nim |
| 05:39:04 | * | pie_ joined #nim |
| 05:52:21 | * | vlad1777d joined #nim |
| 06:11:31 | * | Jesin quit (Quit: Leaving) |
| 06:13:27 | * | rauss quit (Quit: WeeChat 1.7) |
| 06:18:11 | * | Jesin joined #nim |
| 06:21:40 | * | Jesin quit (Remote host closed the connection) |
| 06:22:20 | * | Jesin joined #nim |
| 06:37:54 | * | Jesin quit (Quit: Leaving) |
| 06:54:52 | * | Jesin joined #nim |
| 06:55:46 | * | user0____ joined #nim |
| 06:56:49 | * | user0___ quit (Read error: Connection reset by peer) |
| 06:56:52 | * | user0____ quit (Read error: Connection reset by peer) |
| 06:57:50 | * | nsf joined #nim |
| 06:58:28 | * | user0____ joined #nim |
| 07:02:01 | * | ftsf_ quit (Quit: :q!) |
| 07:15:24 | * | tankfeeder joined #nim |
| 07:24:12 | * | rokups joined #nim |
| 07:24:34 | * | bjz joined #nim |
| 07:36:52 | * | couven92 joined #nim |
| 07:51:01 | * | sz0 joined #nim |
| 08:03:09 | * | Vladar quit (Remote host closed the connection) |
| 08:08:08 | * | vendethiel- joined #nim |
| 08:08:21 | * | vendethiel quit (Ping timeout: 260 seconds) |
| 08:08:47 | * | Vladar joined #nim |
| 08:09:35 | * | gokr joined #nim |
| 08:10:32 | * | chemist69 quit (Quit: WeeChat 1.7) |
| 08:11:06 | * | chemist69 joined #nim |
| 08:12:11 | * | chemist69 quit (Client Quit) |
| 08:13:07 | * | Arrrr joined #nim |
| 08:13:07 | * | Arrrr quit (Changing host) |
| 08:13:07 | * | Arrrr joined #nim |
| 08:13:28 | * | chemist69 joined #nim |
| 08:21:20 | gokr | Vladar: appimage for 64 bit Linux runs fine here too. Ubuntu 16.04. |
| 08:22:01 | Vladar | gokr: thanks for the info |
| 08:22:21 | gokr | Vladar: Nice game - two things that stumped me: 1) Control via mouse? :) I would use WSAD + SPACE for fire. and 2) Fire rate should IMHO be slightly higher. |
| 08:22:33 | gokr | Asteroids is one of my fav games - nicely done! |
| 08:22:41 | Vladar | thanks |
| 08:22:49 | gokr | Regarding game engines etc - did you ever look at Urho3D? |
| 08:23:21 | Vladar | heard of it, I think |
| 08:23:35 | gokr | I of course applaud all 100% Nim efforts - but Urho3D and especially AtomicGameEngine now that is a derivative is VERY nice. |
| 08:23:51 | gokr | Me and especially Araq wrapped Urho3D in Nim a year or so back. |
| 08:24:16 | * | Andris_zbx joined #nim |
| 08:24:32 | gokr | I looked at a lot of engines before we decided to use Urho3D as the new engine for the VR system at 3DICC, where me and Araq worked. |
| 08:24:52 | gokr | https://github.com/3dicc/urhonimo |
| 08:24:56 | gokr | It needs updating though. |
| 08:25:06 | Araq | yup, but now there is also an Unreal Engine 4 wrapper :-) |
| 08:25:27 | gokr | And these days - Atomic has a lot of improvements over Urho3D, while still not being a fork. |
| 08:26:03 | gokr | Advantage of Atomic (IIRC) is that it runs on win/linux/osx/ios/android. I don't think UE4 does mobile. |
| 08:26:24 | Araq | sure it does |
| 08:26:35 | gokr | Ok, perhaps I misremembered. |
| 08:27:17 | Vladar | btw, had anyone tried to build Nim under schroot (32-bit chroot running on 64-bit machine)? getting this error: |
| 08:27:18 | Vladar | # ./build.sh gcc -w -O3 -fno-strict-aliasing -Ic_code -c c_code/2_2/compiler_nim.c -o c_code/2_2/compiler_nim.o |
| 08:27:18 | Vladar | In file included from c_code/2_2/compiler_nim.c:6:0: |
| 08:27:18 | Vladar | c_code/nimbase.h:443:13: error: size of array 'Nim_and_C_compiler_disagree_on_target_architecture' is negative |
| 08:28:29 | Vladar | could I force 32bit arch here? |
| 08:31:58 | Araq | yes |
| 08:32:11 | Araq | well |
| 08:32:42 | Vladar | it might be that I set up schroot wrong, though… |
| 08:33:05 | Araq | edit build.sh perhaps, but shouldn't schroot's uname produce the correct value? |
| 08:33:18 | Vladar | that what I was thinking |
| 08:34:23 | gokr | Araq: Did you play with the UE4 wrapper? |
| 08:35:17 | Araq | not that much, gokr. I rewrote Nim's codegen for it though |
| 08:35:37 | Araq | so that we have much better compile times |
| 08:36:47 | gokr | I am itching to play around a bit with Atomic - but... they added C# support and that's sure pretty neat too. |
| 08:39:36 | Vladar | oh, yeah, missed personality=linux32 |
| 08:51:37 | FromGitter | <vegansk> Araq, closure iterators are unusable :-( https://github.com/nim-lang/Nim/issues/5522 and https://github.com/nim-lang/Nim/issues/5519 |
| 08:59:04 | * | couven92 quit (Quit: Client disconnecting) |
| 08:59:54 | Araq | fix it. dunno about "Unusable" though, the whole .async framework builds on top of them |
| 09:07:23 | * | andris_ joined #nim |
| 09:09:29 | * | Andris_zbx quit (Ping timeout: 240 seconds) |
| 09:28:39 | FromGitter | <Varriount> Araq: How would you suggest those two issues be fixed? |
| 09:30:38 | Araq | investigate why transformVarSection doesn't get what it wants |
| 09:33:24 | Araq | most likely some LL pass already transformed var x to var closureEnv.x and so we need to decide whether that produces a closureEnv.x' copy. |
| 09:33:32 | Araq | or whether we can use this field directly |
| 09:56:48 | * | PMunch joined #nim |
| 10:03:16 | * | Arrrr quit (Disconnected by services) |
| 10:03:16 | * | Arrrr1 joined #nim |
| 10:03:32 | * | Arrrr1 quit (Client Quit) |
| 10:06:39 | * | vendethiel joined #nim |
| 10:07:05 | * | vendethiel- quit (Ping timeout: 260 seconds) |
| 10:13:31 | Vladar | ok, it seems I figured out schroot stuff, here's links to the updated AppImages: https://github.com/Vladar4/ng2planetoids#links |
| 10:13:39 | Vladar | please tell if it runs for you |
| 10:17:41 | Calinou | why is it in a .run |
| 10:18:01 | Calinou | also, don't commit compiled binaries to a Git repository, use GitHub's releases mechanism |
| 10:18:08 | Vladar | because I called it so =) it's an AppImage package |
| 10:18:19 | Vladar | yeah, I should look into it |
| 10:18:22 | Calinou | just use the .AppImage extension |
| 10:18:42 | Calinou | calling it something else may confuse file managers |
| 10:23:31 | Vladar | so, does it work? |
| 10:25:41 | Calinou | it works, yeah |
| 10:25:47 | Calinou | on Manjaro 64-bit (using 64-bit appimage) |
| 10:25:53 | Calinou | so, good job :P |
| 10:26:20 | Vladar | thanks, could move it to the releases properly then |
| 10:31:17 | Vladar | kinda like that https://github.com/Vladar4/ng2planetoids/releases/tag/v1.0 |
| 10:39:35 | Calinou | yes |
| 10:46:48 | * | ftsf quit (Ping timeout: 268 seconds) |
| 10:48:45 | * | ftsf joined #nim |
| 11:02:30 | * | Snircle joined #nim |
| 11:07:50 | * | couven92 joined #nim |
| 11:27:28 | * | gokr quit (Ping timeout: 240 seconds) |
| 11:29:42 | demi- | Araq: i'm having some memory issues (stuff being trampled) and not sure how to go about debugging it, usual tools aren't being helpful; i've got some output from ASAN which seems to indicate a problem but i have no idea if it is related or not. |
| 11:30:37 | Araq | demi-: I'm investigating valgrind reports myself. for this use 'koch valgrind --debugger:native foo.nim' |
| 11:30:47 | Araq | pushed this today. |
| 11:30:48 | FromGitter | <vegansk> @Araq about issue #5519. It works if I just use already transformed variable in line 6 - https://gist.github.com/vegansk/54b02fd2d3bbf00a95108d7095c01861#file-transf-nim-L6 |
| 11:31:10 | Araq | vegansk: told ya :P |
| 11:31:33 | FromGitter | <vegansk> Is it normal, can I make the PR? |
| 11:31:35 | demi- | yeah unfortunately valgrind apparently doesn't support 10.12 and i don't have a computer is on anything else. |
| 11:32:09 | Araq | demi-: do you know about -d:useSysAssert -d:useGcAssert already? |
| 11:32:31 | demi- | no i don't, i will try enabling them to see what happens |
| 11:33:27 | Araq | hmm I'm on 10.11.6 osx |
| 11:33:56 | Araq | and valgrind doesn't support 10.12? strange |
| 11:33:59 | demi- | just repro'd with those flags can got a pretty similar stacktrace lead by `[GCASSERT] doOperation 2` |
| 11:34:20 | Araq | ^ this. |
| 11:34:32 | Araq | can I see the program that causes it? |
| 11:34:35 | demi- | it apparently has "preliminary support" but not installable via brew |
| 11:35:38 | demi- | yeah one sec let me push up the latest changes |
| 11:36:47 | FromGitter | <vegansk> @Araq, there is another problem. If I use the same variable names in tuple destructuring in another block, nim generates the same symbols for them. And then c compiler fails with `` duplicate member`` errors. |
| 11:37:48 | Araq | vegansk: the field transformation actually appends some ID iirs to prevent this from happening |
| 11:40:54 | Araq | ah hmm |
| 11:41:21 | Araq | checkout compiler/lowerings.nim proc addField and addUniqueField |
| 11:41:40 | Araq | actually, only addUniqueField |
| 11:42:06 | FromGitter | <vegansk> @Araq, got it |
| 11:42:23 | FromGitter | <Almynic> does nim support quadruple-precision floating-point numbers? |
| 11:42:38 | Araq | make for the skField s.flags.incl sfAnon |
| 11:43:23 | demi- | Araq: ok here are instructions for getting it running: https://gist.github.com/samdmarshall/024f94444144c4a1305cdfe25a42019f |
| 11:43:25 | Araq | and in the codegen patch mangleField (ccgtypes.nim) if the field as sfAnon, add its line number |
| 11:43:56 | demi- | also fwiw, i tried this on the 0.16.0 release as well as latest from master |
| 11:44:35 | Araq | you mean 'devel', right? |
| 11:44:42 | Araq | do you use async? |
| 11:46:11 | demi- | yes, sorry; and no i don't use async this is purely synchronous code |
| 11:46:41 | Araq | almynic: no. |
| 11:49:49 | Araq | demi-: necromancy/src/nimcache/necromancy_necromancy.c:14:10: fatal error: 'termbox.h' file not found |
| 11:50:08 | demi- | did you install the termbox library? |
| 11:50:48 | * | gokr joined #nim |
| 11:51:40 | Araq | yes |
| 11:51:54 | FromGitter | <Almynic> @araq Thank you then the type suffix 'f128 in the nim manual, is only a normal float without higher precision right? |
| 11:52:04 | Araq | brew install termbox |
| 11:52:04 | Araq | Warning: termbox-1.1.0 already installed |
| 11:52:48 | Araq | almynic: it's reserved for the future. |
| 11:52:50 | demi- | you may need to modify the nim.cfg depending on where it installed to? it should be the same as it already is coming from brew |
| 11:53:08 | demi- | unless you have a custom brew location |
| 11:54:04 | FromGitter | <Almynic> @Araq ok thanks for clarifying my confusion ;) |
| 11:55:59 | Araq | demi-: you don't do anything like --cincludeDir |
| 11:56:06 | Araq | how could it work? |
| 11:57:43 | Araq | HOMEBREW_PREFIX: /usr/local |
| 11:57:43 | Araq | HOMEBREW_REPOSITORY: /usr/local/Homebrew |
| 11:57:43 | Araq | HOMEBREW_CELLAR: /usr/local/Cellar |
| 11:57:53 | Araq | that's what my 'brew config' says |
| 11:58:23 | * | couven92 quit (Quit: Leaving) |
| 12:00:12 | demi- | i am not sure what to say, `/usr/local/include` apparently gets included for me already, |
| 12:03:26 | demi- | there isn't any reason why this couldn't also run on linux, i believe the flags i have setup should be compatible with the linker on linux if you are more comfortable working there |
| 12:03:48 | demi- | the only dependency is termbox |
| 12:04:37 | Araq | well I have /usr/local/include/termbox.h so never mind |
| 12:18:06 | * | elrood joined #nim |
| 12:24:56 | Araq | demi-: well it crashes for me too and makes my terminal unusable afterwards |
| 12:27:13 | Araq | ViewContents* {.union.} = object |
| 12:27:13 | Araq | text*: TextView |
| 12:27:13 | Araq | label*: LabelView |
| 12:27:15 | Araq | browser*: FileBrowser |
| 12:27:17 | Araq | selector*: SelectorView |
| 12:27:19 | Araq | input*: InputView |
| 12:27:31 | Araq | <-- that is very wrong, remove the .union |
| 12:27:55 | Araq | https://nim-lang.org/docs/manual.html#foreign-function-interface-union-pragma |
| 12:28:10 | Araq | "The object declaration then must not use inheritance or any GC'ed memory but this is currently not checked." |
| 12:29:56 | Araq | I removed the .union and the crashes disappear. :-) |
| 12:30:21 | Araq | so ... unfortunately that's not the corruption I'm hunting |
| 12:34:45 | demi- | was the ASAN info i posted last night useful or bogus? |
| 12:36:29 | demi- | ahh, ok thank you Araq. I was under the impression i could use that to simulate a C union but i guess not |
| 12:36:58 | Araq | you can use a 'case' in the object to save some space |
| 12:37:06 | Araq | but .union is only for C interop |
| 12:40:20 | demi- | if i fix the union usage, and turn ASAN back on i still get this message with an abnormal exit: https://gist.github.com/samdmarshall/dbfe576b2cb607b8303cd6548b2f4d63 |
| 12:42:29 | * | gokr quit (Ping timeout: 260 seconds) |
| 12:46:29 | * | couven92 joined #nim |
| 12:46:55 | * | gokr joined #nim |
| 12:49:57 | * | zachcarter_ joined #nim |
| 12:50:41 | * | zachcarter quit (Ping timeout: 260 seconds) |
| 12:50:41 | * | zachcarter_ is now known as zachcarter |
| 12:53:05 | FromGitter | <Varriount> demi-: Have you tested ASAN to make sure it works on a working program that uses garbage collection? |
| 12:53:47 | demi- | you mean something not written in nim? |
| 12:54:36 | FromGitter | <Varriount> No, I mean a program written in Nim, that you are sure runs correctly, that uses garbage collection. |
| 12:55:54 | FromGitter | <Varriount> I know that Valgrind requires a special file so it doesn't mistake the garbage collection internals as erroneous. |
| 12:57:47 | demi- | hmmm, it seems to work on on other nim programs, |
| 12:59:24 | Araq | varriount: nim ships with a suppress file. |
| 12:59:43 | Araq | demi-: varriount is correct the address sanitizer doesn't understand Nim's stack tracing |
| 12:59:49 | Araq | that is required by the GC |
| 13:00:13 | demi- | do you know of any way to get it to work? |
| 13:01:19 | demi- | oh, and my mistaken usage with union: will that become a compiler error/warning at some point? |
| 13:01:49 | Araq | as the manual says, yes |
| 13:01:56 | Araq | the compiler will prevent it |
| 13:02:24 | FromGitter | <Varriount> Araq: Huh. It's that suppress file mentioned anywhere in the documentation? |
| 13:02:30 | demi- | ok, sounds good, thanks |
| 13:03:04 | Araq | varriount: use 'koch valgrind foo.nim' |
| 13:03:15 | Araq | no docs, the feature arrived yesterday. |
| 13:04:26 | FromGitter | <Varriount> demi-: I'm assuming you're running OSX El Capitan? That's the most common platform Valgrind won't run on. |
| 13:05:00 | demi- | i'm running sierra |
| 13:05:42 | FromGitter | <Varriount> Huh, I thought Sierra was supported. |
| 13:05:58 | demi- | there is "preliminary support" whatever that means |
| 13:06:02 | FromGitter | <Varriount> Or am I getting versions mixed up. |
| 13:06:12 | demi- | sierra is 10.12, capitan is 10.11 |
| 13:06:22 | FromGitter | <Varriount> Ah, ok. |
| 13:06:36 | demi- | but I cannot install valgrind through homebrew and i especially don't fancy doing it myself |
| 13:06:41 | * | bjz quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 13:07:17 | demi- | since it may not even work correctly |
| 13:07:44 | FromGitter | <Varriount> I wonder what's changed on the OS level to prevent Valgrind from working... |
| 13:07:56 | demi- | probably nothing |
| 13:08:13 | demi- | but that is what the documentation says for valgrind |
| 13:08:47 | FromGitter | <Varriount> By the way, I like your Github avatar. |
| 13:09:09 | FromGitter | <Varriount> I need to change mine at some point |
| 13:09:12 | demi- | thanks |
| 13:41:22 | Araq | demi-: I'm afraid you have to disable AddressSanitizer or patch it about the markStackAndRegisters_LdwvBL9bC9c0lik7K9bau9bX0Q call doing dangerous stuff |
| 13:42:36 | * | rauss joined #nim |
| 13:43:54 | couven92 | BTW, I have discovered that it actualy would make more sense to have the vccexe (the Visual C Compiler XPlat helper) as its own nimble package... Can I remove it from tools and make it standalone? I also found some bugs I need to adress and I want to add Visual Studio 2017 support... |
| 13:44:20 | * | rauss quit (Client Quit) |
| 13:45:12 | * | rauss joined #nim |
| 13:46:36 | demi- | Araq: hmmm ok, i've gone ahead and reached out to some friends on the llvm project team to see if i can get some more info about working with it; will write up any instructions i can once i get it working |
| 13:47:25 | Araq | couven92: that would be sad. |
| 13:47:32 | Araq | I accept patches. |
| 13:47:44 | Araq | I think it's nice to have this in the core |
| 13:48:44 | couven92 | okay... But it needs some redesign as it does not really work well when compiling vccexe with and old vccexe... (replacement problem... same as koch produces nim1 before it creates nim) |
| 13:49:17 | couven92 | Well... That means a redesign in the `koch tools` command, right? |
| 13:51:25 | hohlerde | does GC_ref and GC_unref work with cstring? |
| 13:56:07 | Araq | couven92: hmm? why? |
| 13:56:27 | Araq | hohlerde: no, you use it for the 'string' before converting it to cstring |
| 14:02:04 | hohlerde | araq: thx, will try it. |
| 14:02:11 | * | cheatfate quit (Quit: Leaving) |
| 14:08:07 | demi- | Araq: i assume PRs to make nim's GC system compatibile with ASAN are welcome? |
| 14:09:13 | Araq | yeah but don't underestimate the effort. the conservative stack scanning is essential for the GC to work |
| 14:09:39 | Araq | and an alternative would require large codegen changes |
| 14:09:56 | * | cheatfate joined #nim |
| 14:10:06 | demi- | mhmm, i think i have enough info about ASAN to mark stuff to be ignored properly |
| 14:10:12 | Araq | Ruby should be affected by this too though. |
| 14:10:29 | * | BitPuffin|osx joined #nim |
| 14:10:30 | Araq | as it uses a similar GC implementation for this. at least older Ruby versions did. |
| 14:11:11 | demi- | the GC methods that are available to the compiler, are those collection patterns or are they entirely separate implementations? |
| 14:14:32 | Araq | separate algorithms on top of the same core |
| 14:14:51 | demi- | ok, so i'd be working with the same set of functions then |
| 14:15:16 | Araq | except gc:go and gc:boehm, these mostly delegate the work to the external GC |
| 14:16:02 | Araq | demi-: yes. it would be a single patch |
| 14:16:15 | Araq | affecting all of our "native" GCs |
| 14:16:19 | demi- | ok cool, thanks |
| 14:16:36 | * | girvo quit (Ping timeout: 240 seconds) |
| 14:17:48 | Araq | I can also guide you about how this needs to be done. |
| 14:17:58 | Araq | but I won't do it myself. |
| 14:18:36 | demi- | heh, no worries |
| 14:26:51 | demi- | Araq: hmmm, this gives new impetus to have a way to resolve runtime symbols, I might not need to even submit a code patch, just an additional file to use as a blacklist for the functions that should be ignored. |
| 14:30:04 | couven92 | Araq, for vccexe... Currently it searches for the presence of the VS<VERSION>COMNTOOLS environment variable... VS2017 no longer defines any env-variables to allow for side-by-side... Should I implement Registry Search instead? (that's how you'd find the Visual Studio C Compiler without env-vars) |
| 14:31:02 | couven92 | vccexe should probably also take another argument specifying the compiler version you use (if you have multiple versions installed) and use the newest by default... |
| 14:35:57 | cheatfate | couven92, and where in registry you will search? |
| 14:36:40 | cheatfate | also you are wrong about vs2017 no longer defines any env-variables... because vcvarsXX.bat still exists |
| 14:36:53 | cheatfate | so there only problem to find it |
| 14:37:43 | couven92 | yes, but currently I use the VS140COMNTOOLS env-var (for VS 2015) to find the vcvarsall.bat |
| 14:38:00 | couven92 | VS2017 does not define a new VSXXXCOMNTOOLS variable |
| 14:38:10 | cheatfate | yeah i know |
| 14:38:17 | couven92 | ergo: finding the VS2017 compiler is (more) difficult |
| 14:38:30 | cheatfate | asking where in registry exactly start searching? |
| 14:38:52 | couven92 | Hmm... incidentally, VS2017 does not write itself into HKLM/Software/Microsoft/VisualStudio either... |
| 14:38:54 | couven92 | Hmm... |
| 14:39:36 | cheatfate | you need to use HKCU |
| 14:40:25 | couven92 | nope, only contains the licenses |
| 14:41:03 | couven92 | But: You'll need to look at the 32-bit view Registry... i.e. HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\VisualStudio\15.0 |
| 14:41:12 | couven92 | (Always forget that... :/ ) |
| 14:42:35 | * | tankfeeder quit (Quit: Leaving) |
| 14:43:29 | * | girvo joined #nim |
| 14:44:22 | couven92 | cheatfate, Hmm... Microsoft's answer to this: vswhere ( https://blogs.msdn.microsoft.com/heaths/2017/02/25/vswhere-available/ ) |
| 14:46:11 | cheatfate | and where to find vswhere? :) |
| 14:46:18 | couven92 | GitHub |
| 14:46:39 | couven92 | However I still think that using the Registry to find the older (14.0 and below) is better than using environment variables |
| 14:46:59 | couven92 | cheatfate, https://github.com/Microsoft/vswhere |
| 14:47:17 | cheatfate | couven92, so you propose to bundle vswhere with nim distribution... |
| 14:47:34 | couven92 | that would be very sad, indeed |
| 14:47:59 | couven92 | but hey, it's on GitHub! Shall I write vswhere-nim? :P |
| 14:48:09 | cheatfate | i think you are also wrong with registry approach, because i think trees was incompatible with each other... |
| 14:48:24 | cheatfate | couven92, for the first you will need to handle COM with Nim... |
| 14:49:01 | cheatfate | currently we have only one nimble package with COM inside and it 3mb of nim source code... |
| 14:49:02 | couven92 | Oh, crap... yeah you're right... didn't think of that... |
| 14:49:25 | couven92 | vswhere is cpp |
| 14:49:39 | cheatfate | you dont need cpp to handle COM |
| 14:49:56 | couven92 | But why do I need COM for vswhere? |
| 14:50:49 | cheatfate | https://github.com/Microsoft/vswhere/blob/develop/src/vswhere/Program.cpp |
| 14:51:24 | cheatfate | it looks like it using COM to enumerate properties |
| 14:52:06 | * | girvo quit (Ping timeout: 240 seconds) |
| 14:52:13 | couven92 | Ah... yes you're right: https://github.com/Microsoft/vswhere/blob/develop/src/vswhere/stdafx.h#L22 |
| 14:55:17 | couven92 | But cheatfate, from the vcxproj files, it looks as if all the COM stuff is simply pointers from imported windows dlls... It looks like Nim should be able to do this... |
| 14:56:26 | * | xet7 quit (Quit: Leaving) |
| 15:00:12 | Araq | we have registry.nim in the stdlib. barebones, but might suffice. |
| 15:01:53 | couven92 | Ok... I'll create PR as soon as I get home and start playing with this... |
| 15:02:58 | cheatfate | couven92, i can give you a `hack way` for this |
| 15:03:25 | cheatfate | COM components have stable UUID (always) |
| 15:03:49 | cheatfate | you can find `InProcServer` for UUID (which will be path to dll) |
| 15:03:53 | cheatfate | maybe this helps |
| 15:04:18 | cheatfate | but of course normal way is to use COM to get installation directories |
| 15:04:25 | couven92 | ooh... right... I'll have a look and if all fails I'll try to port vswhere to nim |
| 15:04:44 | cheatfate | but i dont like latest nimble package with windows api for 3mb of useless declarations |
| 15:04:55 | cheatfate | but it has some COM features |
| 15:04:57 | cheatfate | inside |
| 15:05:09 | couven92 | I'll try to keep it small |
| 15:05:10 | cheatfate | i dont like it too, because it looks unsafe |
| 15:05:20 | cheatfate | but my own com package still not ready |
| 15:06:20 | couven92 | Araq, PMunch and I are trying to get wxWidgets to run... We concluded with creating a nim.cfg with when statements to account for Linux/Windows and GCC vs. VCC link artifacts... We also discussed to create the wxWidgets repo as a submodule to your Araq/wxnim repo... |
| 15:07:55 | PMunch | That way you could (on platforms that don't support a system wide install through a package manager and use of `wx-config <flags>`) grab wxWidgets from their repositories in the correct spot so the user won't have to make sure it's in the right folder and uch. |
| 15:08:18 | * | Sentreen quit (Quit: WeeChat 1.4) |
| 15:14:10 | * | Sentreen joined #nim |
| 15:16:18 | demi- | Araq: is there any way i could have an attribute appended to a function in the system library? seems like `emit` isn't allowed on proc declarations :( |
| 15:48:24 | * | girvo joined #nim |
| 15:52:52 | * | girvo quit (Ping timeout: 258 seconds) |
| 16:03:06 | * | pie_ quit (Ping timeout: 240 seconds) |
| 16:12:31 | * | Jesin quit (Quit: Leaving) |
| 16:17:10 | * | Jesin joined #nim |
| 16:17:17 | * | nsf quit (Quit: WeeChat 1.7) |
| 16:20:40 | * | gokr quit (Quit: Leaving.) |
| 16:21:55 | Araq | PMunch, couven92 fine with me though I wouldn't use git submodules. ever. |
| 16:22:29 | Araq | demi-: .emit for proc declaration? are you looking for .codegenDecl ? |
| 16:23:42 | demi- | maybe? if i can stick another __attribute__ on `markStackAndRegisters` then I can use ASAN seemingly flawlessly. |
| 16:23:57 | demi- | and i'm trying to work out how to do that without adding a new pragma or compiler flag |
| 16:24:13 | Araq | yes, .codegenDecl is what you need |
| 16:24:50 | zachcarter | I’ve written new nim-bgfx bindings as the current ones are very broken |
| 16:24:53 | demi- | aaah, i see. thank you |
| 16:25:07 | zachcarter | these ones don’t seem to have the stack corruption issues the old ones do, so no freezes / lockups when using sdl2 |
| 16:28:15 | Araq | zachcarter: yay :-) |
| 16:28:49 | zachcarter | until we have our own Nim cross platform graphics API these bindings will ahve to do :) |
| 16:29:04 | Araq | we have graphics.nim |
| 16:29:09 | zachcarter | I mean something like bgfx |
| 16:29:20 | zachcarter | I guess I worded my last sentece incorrectly |
| 16:29:27 | Araq | that still uses SDL 1. I dunno what bgfx means |
| 16:29:33 | zachcarter | a Nim library that is graphics API agnostic |
| 16:29:35 | Araq | what features does it offer? |
| 16:29:52 | zachcarter | depending on the device it is running on it will render via directx, opengl, opengles, vulkan, metal, etc... |
| 16:30:00 | zachcarter | via one API |
| 16:30:33 | zachcarter | you also write shaders in one language |
| 16:31:05 | zachcarter | it’s quite the library if you want to do cross platform hardware accelerated graphics |
| 16:32:58 | demi- | Araq: I am declaring an emit right before the proc I want it to impact as i have to conditionally declare this attribute using a macro, however that doesn't seem to be carried to the same location as the proc's c function is declared at, is there any way to get these to correlate? |
| 16:34:28 | cheatfate | zachcarter, please don't call wrapper as `nim library` |
| 16:35:01 | demi- | this is what my patch looks like right now: https://gist.github.com/samdmarshall/cc660adb962cb12e388a2fc5c2879abd |
| 16:35:19 | zachcarter | okay cheatfate, a Nim wrapper |
| 16:35:35 | zachcarter | if you want to get technical it would be a Nim API right? |
| 16:35:42 | Araq | demi-: there is no such connection but you can start the emit with """/*typesection*/ |
| 16:36:04 | Araq | or better add it to nimbase.h |
| 16:36:27 | cheatfate | zachcarter, there is no Nim API |
| 16:36:34 | zachcarter | ... |
| 16:36:35 | cheatfate | because Nim is a language |
| 16:36:39 | zachcarter | I’m saying you’d be writing an API in Nim |
| 16:36:40 | cheatfate | so it has no api |
| 16:36:44 | zachcarter | I think you misunderstand my English |
| 16:37:17 | cheatfate | it just nim wrapper for bgfx library |
| 16:37:31 | zachcarter | no that’s not what I was describing in that sentence cheatfate |
| 16:37:42 | zachcarter | I was saying until Nim has something like BGFX, bindings to BGFX will have to do |
| 16:37:46 | zachcarter | that was my sentiment |
| 16:40:23 | demi- | Araq: that worked, is there any documentation i should be adding or updating to make account for this in the future? |
| 16:42:02 | Calinou | BGFX is not very useful in practice, just saying |
| 16:42:25 | Araq | https://nim-lang.org/docs/manual.html#implementation-specific-pragmas-emit-pragma |
| 16:42:28 | Calinou | (I speak as a Godot contributor, we occasionally get requests about it, but we keep turning them down because modern OpenGL ES works well on all platforms) |
| 16:42:49 | Araq | „For a toplevel emit statement the section where in the generated C/C++ file the code should be emitted can be influenced via the prefixes /*TYPESECTION*/ or /*VARSECTION*/ or /*INCLUDESECTION*/:“ |
| 16:43:38 | Araq | yeah I know our docs are bad but that's not an excuse for not using them. :P |
| 16:43:45 | couven92 | Araq, ok... PMunch and I see the problem with distributing wxWidgets as a submodule... I just compiled wxWidgets for both x86 and x64 and that's all in all 3.56GiB |
| 16:44:50 | PMunch | That's why I want to use `wx-config` and the ~30MiB wxGtk package installed on my system.. |
| 16:46:30 | Araq | I preferred to be independent of wx-config crap |
| 16:46:54 | couven92 | Hmm... could work to have a --with-wxWidgets strategy (similar to autoconf's configure) which would give people the oppurtunity to specify the path to a wxWidgets installation |
| 16:47:25 | Araq | you should just embrace the ../ sibling path solution. |
| 16:47:42 | couven92 | okay... point taken :D |
| 16:48:04 | Araq | assume the wxWidgets is the sibling, but also provide binaries for convenience |
| 16:48:07 | * | zahary_ is now known as zahary |
| 16:48:24 | * | Trustable joined #nim |
| 16:48:26 | zachcarter | Calinou: modern opengl es does work well, but if you can support more rendering backends I don’t understand why you wouldn’t want to |
| 16:48:46 | zachcarter | Godot doesn’t want to use BGFX because why would it, it already has a renderer written using OpenGL ES |
| 16:48:49 | zachcarter | I don’t have one... |
| 16:49:10 | zachcarter | I think BGFX is plenty useful |
| 16:49:29 | PMunch | But if I want to have multiple programs using wxWidgets, I'll need to edit all my nim.cfg files or symlink/copy the wxWidgets folder around. On Linux it's simply a lot neater to use wx-config, since it's whole point is to point you to the includes and libs you need. |
| 16:50:51 | Araq | demi-: but as I said, please add this C #define to nimbase.h, that's where it belongs |
| 16:51:08 | demi- | yeah i have, i'm writing some documentation above that |
| 16:52:10 | Araq | PMunch: no, you point your config to wxnim and relative to wxnim's there is ../wxWidgets with binaries wxnim uses |
| 16:52:54 | Araq | wx-config doesn't change anything since you have the very same problem for wxnim, how can your Nim programs find it. |
| 16:52:57 | PMunch | Still, wxWidgets is 1.9GB. The wxGtk package is 30MiB.. |
| 16:53:13 | PMunch | When you install wxGtx it puts it in your path |
| 16:53:19 | PMunch | So you call it from anywhere |
| 16:53:33 | PMunch | Don't need to know where it is.. |
| 16:53:55 | Araq | no, you only need to know wx-config is in your PATH |
| 16:54:05 | Araq | you only move the problems around. |
| 16:54:51 | couven92 | PMunch, don't assume that people won't fuck up their PATH! I do it all the time!! :P |
| 16:54:54 | PMunch | But the problem would be simple to solve.. "sudo pacman -S wkGtk && nimble install wxnim && nim cpp -r myapp.nim" |
| 16:55:20 | couven92 | If you have and want to use pacman! |
| 16:55:20 | PMunch | That's all it would take for a Linux user to compile and run a wxNim application |
| 16:55:33 | PMunch | And the install would take ~3 minutes |
| 16:55:52 | Araq | PMunch: nimble has distros.nim support for that |
| 16:56:03 | PMunch | couven92, obviously that would be specific to your distro. You can replace that with apt-get or yum if you want. |
| 16:56:22 | couven92 | if you have and want to use yum or apt-get |
| 16:56:29 | Araq | but you still need a solution for Windows. |
| 16:56:36 | Araq | ship with the DLLs or something. |
| 16:56:39 | PMunch | couven92, and you would if you were on a Linux system.. |
| 16:56:59 | Araq | I don't mind wx-config if *you* ensure the linux package manager is used for that |
| 16:57:10 | Araq | but don't just assume wx-config exists. it doesn't. |
| 16:57:22 | Araq | lol |
| 16:57:29 | Araq | I meant to emphasize the *if* |
| 16:57:49 | PMunch | Oh yeah, this would only be for Linux systems |
| 16:57:51 | couven92 | Araq, solution for both Linux and Windows: https://github.com/couven92/wxnim/blob/vcc/examples/nim.cfg |
| 16:58:04 | couven92 | (and without submodules) |
| 16:58:15 | PMunch | Yeah, forgot that was in a private chat :P |
| 16:58:36 | * | brson joined #nim |
| 16:58:41 | PMunch | 100-101 is what I want to replace with just wx-config |
| 16:59:05 | couven92 | PMunch, no this is a new one... because we didn't like the submodule, I had to change all the paths :P |
| 16:59:20 | PMunch | Yeah, but just ditch the path for Linux |
| 17:02:23 | PMunch | Oh, and remove --threads:on |
| 17:02:30 | PMunch | That was for something else |
| 17:03:04 | demi- | Araq: https://github.com/nim-lang/Nim/pull/5536 |
| 17:08:30 | * | gokr joined #nim |
| 17:08:38 | Araq | def-: gc_ms.nim is also affected |
| 17:08:45 | Araq | test with --gc:markAndSweep |
| 17:14:39 | * | andris_ quit (Remote host closed the connection) |
| 17:15:16 | demi- | ok, seems like i should be marking decRef as well, but that gets inlined, so i'd have to either uninline or mark where it gets used |
| 17:22:08 | * | Trustable quit (Remote host closed the connection) |
| 17:26:56 | * | gokr quit (Quit: Leaving.) |
| 17:27:01 | * | arnetheduck quit (Ping timeout: 268 seconds) |
| 17:28:58 | ldlework | maybe it was cligen was crap |
| 17:29:10 | ldlework | Oh something about talking to docker daemon over a unix domain socket |
| 17:29:14 | ldlework | dom96: that's what it was |
| 17:29:22 | couven92 | Okay Araq, PMunch and I have merged and the new xplat supporting nim.cfg is your wxnim pull #3 |
| 17:29:24 | ldlework | show me how to do http over domain sockets and I might give nim another chance |
| 17:29:29 | Xe | doing HTTP over a unix domain socket is painful more than it should be |
| 17:29:38 | ldlework | Ya |
| 17:29:53 | PMunch | couven92, just a sec. I'm rewriting the README |
| 17:29:57 | ldlework | I barely have time for this pet project :) |
| 17:31:26 | cheatfate | Xe, create unix socket, wrap it to AsyncSocket and use with httpclient.nim... is it so hard? |
| 17:31:38 | Xe | cheatfate: code sample plox |
| 17:31:58 | ldlework | cheatfate: yeah I wouldn't even know where to start with that |
| 17:32:12 | ldlework | Maybe httpclient should just accept unix:// like in other languages |
| 17:32:40 | cheatfate | somebody must make it possible... |
| 17:33:31 | ldlework | cheatfate: go ahead. ..is it so hard? |
| 17:34:16 | cheatfate | somebody can bountysource this feature and somebody can implement it |
| 17:35:59 | ldlework | Well, I am only here to report why it gave up on Nim to avoid the unnecessary guilt-frowns from dom96 |
| 17:36:05 | ldlework | s/it/I |
| 17:36:13 | ldlework | :) |
| 17:42:05 | PMunch | There, rewrote the README and added some screenshots (if anyone wants to contribute an OSX screenshot it would be nice to have that as well :)) |
| 17:43:28 | couven92 | PMunch, would be nice to see if it actually works with OSX! :P |
| 17:44:10 | couven92 | Oh... and someone should test that I didn't fuck up Araq's original MinGW-GCC compile options for Windows... (I have only tested with VCC) |
| 17:44:43 | PMunch | Oh yeah, the nim.cfg probably doesn't have anything that would work on Macs does it? |
| 17:45:07 | PMunch | Do you get wx-config on OSX? Can you install wx through brew? |
| 17:47:36 | couven92 | well... the nim.cfg actually only explicitly recognized special options for Windows... everything else is pretty much captured through the magic of else |
| 17:49:22 | * | girvo joined #nim |
| 17:51:58 | * | kier quit (Ping timeout: 240 seconds) |
| 17:52:50 | couven92 | however if you try to compile using sth else than gcc or vcc you're out of luck... :P |
| 17:54:09 | * | girvo quit (Ping timeout: 268 seconds) |
| 17:54:46 | dom96 | ldlework: Fair enough. |
| 17:55:12 | Araq | I don't know why anybody would use unix domain sockets for anything. isn't TCP the worldwide standard? |
| 17:55:45 | * | rupil joined #nim |
| 17:56:16 | dom96 | Unfortunately, sometimes, if you just want to get shit done Nim isn't the right choice. |
| 17:56:27 | * | kier joined #nim |
| 17:57:22 | dom96 | At this early stage it's up to the user to implement whatever they need. |
| 18:00:09 | Araq | aha got it, Unix domain sockets are not sockets, they are just streams for IPC on the same machine |
| 18:01:07 | ldlework | Araq: yeah they are faster and more 'secure' or whatever |
| 18:01:08 | dom96 | Lack of time is a good excuse, but if there is another reason then we (mainly myself and Araq) need to be told what it is. |
| 18:01:24 | ldlework | But whatever the reason, tons of software utilizes them, from like the outset of unix to today. |
| 18:02:13 | ldlework | I think you're like "I need a good reason to know why to unix sockets" you're just not interacting with much real world linux administration |
| 18:02:21 | Araq | ldlework: seems like our nativesockets module can be used for them, but I'm not sure |
| 18:02:21 | ldlework | which is fine, but nim -is- a systems language |
| 18:02:48 | ldlework | Araq: yeah I think I saw that something could use them but I had like no idea how I would get that to work with httpclient |
| 18:03:03 | Araq | *shrug* I cannot know everything. |
| 18:03:16 | ldlework | not yet. |
| 18:04:40 | dom96 | You can certainly interact with them in Nim, the question is how easy it is. |
| 18:04:55 | cheatfate | Araq, unix domain sockets used mostly to have one compatible mechanism for inter networking and local networking... and because unix domain sockets almost equal in speed with pipes, it preferred for localhost connections |
| 18:05:23 | cheatfate | ordinary tcp sockets are not so fast as unix domain sockets |
| 18:06:42 | cheatfate | to create unix socket u just need to AF_INET replace with AF_UNIX |
| 18:06:59 | cheatfate | everything else is almost equal |
| 18:08:00 | cheatfate | but httpclient.nim will also needs to be modified to recognize unix:// scheme |
| 18:08:12 | * | couven92 quit (Quit: Client disconnecting) |
| 18:08:18 | cheatfate | because unix names are not URI names |
| 18:09:29 | dom96 | if that's all it takes then it's much easier than I thought |
| 18:14:51 | * | Matthias247 joined #nim |
| 18:20:36 | ldlework | |
| 18:40:12 | * | kulelu88 joined #nim |
| 18:40:58 | demi- | Araq: i'm not sure _i_ can get this to work properly for markAndSweep, if you were to accept the PR would it have to be implemented for all forms of GC? |
| 18:41:26 | demi- | at least not without modifying the code in ways I'm that may negatively impact lang perf |
| 18:42:26 | Araq | demi-: sure I can do it for you. no worries. but it's as simple as you did for gc.nim |
| 18:44:09 | demi- | yeah, i tried, but it wasn't seeming to have an impact and ended up feeling like i was marking methods haphazard which typically indicates lack of enough info to properly fix it |
| 18:45:03 | demi- | most of the problems center around decRef being inlined, and not being able to mark it on its own, looks like everything else is in collectCT/collectCTBody/collectZCT |
| 18:47:08 | * | def-pri-pub joined #nim |
| 18:47:12 | kulelu88 | Does nim have a decent regex lib? |
| 18:47:55 | def-pri-pub | zachcarter: Hey, I'm trying to play with your soloud Nim bindings, but I can't get soloud itself to compile on Linux. Have you been able to do so? |
| 18:48:48 | zachcarter | def-pri-pub: I’ve managed to get the library compiled on Ubuntu using GENie but I haven’t managed to get the bindings to work yet |
| 18:49:10 | zachcarter | on that OS |
| 18:49:25 | zachcarter | I also haven’t managed to get all of the examples to compile for soloud, like the C examples and stuff |
| 18:49:44 | zachcarter | I’m currently working on my own bgfx wrapper and then I plan on paying some more attention to soloud |
| 18:50:23 | cheatfate | dom96, also getAddrInfo must be modified to support not only AF_INET/AF_INET6 but AF_UNIX too |
| 18:55:00 | Araq | demi-: that decRef needs to be annotated is weird. |
| 18:56:24 | demi- | that is the stacktrace i am seeing from ASAN, it fails in decRef. I can try to repro it outside of the curses code i'm working with so i can get readable results and post it to the PR. i'd like to finish this up rather than leave it half-baked. |
| 18:58:22 | def-pri-pub | zachcarter: I've been running into this issue when attempting to compile with GENie |
| 18:58:27 | def-pri-pub | https://www.reddit.com/r/linuxquestions/comments/5zdqr3/need_some_help_figuring_out_where_to_place_that/ |
| 18:58:28 | * | nsf joined #nim |
| 18:58:33 | def-pri-pub | Do you know what the solution might be? |
| 18:59:19 | zachcarter | let me see how I compiled it, one second |
| 19:01:59 | Araq | demi-: also it fails on Windows with: |
| 19:02:03 | Araq | C:\projects\nim\lib/nimbase.h:43:22: error: missing binary operator before token "(" |
| 19:02:03 | Araq | # if __has_attribute(no_sanitize_address) |
| 19:02:03 | Araq | ^ |
| 19:02:32 | Araq | I think this should only be enabled for clang |
| 19:02:35 | demi- | is this with GCC on windows? |
| 19:02:39 | Araq | yes. |
| 19:03:17 | demi- | GCC 4.8+ is supposed to support this attribute, but maybe it doesn't support that check |
| 19:03:36 | demi- | yeah we can make it just supporting clang, i was following the official docs on that define |
| 19:03:49 | Araq | does GCC support ASAN? |
| 19:04:38 | demi- | the library, yeah |
| 19:05:00 | demi- | https://github.com/google/sanitizers/wiki/AddressSanitizer#getting-addresssanitizer |
| 19:05:02 | zachcarter | def-pri-pub: try this |
| 19:05:12 | zachcarter | git clone soloud && cd soloud |
| 19:05:19 | zachcarter | cd build && genie cmake |
| 19:05:33 | zachcarter | cd cmake && mkdir build |
| 19:05:38 | def-pri-pub | I was using gmake, so cmake might be the trick? |
| 19:05:42 | zachcarter | cmake works |
| 19:05:57 | zachcarter | BUT only for building the libraries |
| 19:06:04 | zachcarter | building the examples, like simplest, cmake bombs out |
| 19:06:15 | zachcarter | haven’t had time to dive into why yet |
| 19:06:43 | zachcarter | I get similar errors as you with gmake I’m guessing it’s missing linker flags |
| 19:06:59 | zachcarter | but I don’t want to mess with that makefile it looks hellacious |
| 19:07:05 | def-pri-pub | well, at least there a .so file now |
| 19:07:07 | def-pri-pub | :) |
| 19:07:22 | zachcarter | there you go |
| 19:07:34 | demi- | Araq: i also came across this problem when working on the PR: https://github.com/nim-lang/Nim/issues/5537 |
| 19:12:12 | zachcarter | dom96: https://gist.github.com/zacharycarter/0664d015fda551a0f327c75dc9656eae |
| 19:12:28 | * | kulelu88 quit (Ping timeout: 240 seconds) |
| 19:12:39 | zachcarter | or anyone for that matter |
| 19:12:49 | zachcarter | why is nimble trying to use hg git to d/l a dependency from github? |
| 19:12:52 | * | couven92 joined #nim |
| 19:13:12 | zachcarter | sorry it’s using mercurial not even hg git |
| 19:13:30 | zachcarter | oh I know I’m stupid my bad sorry |
| 19:14:50 | * | gokr joined #nim |
| 19:26:27 | * | gokr quit (Quit: Leaving.) |
| 19:26:43 | * | gokr joined #nim |
| 19:26:59 | * | Jesin quit (Quit: Leaving) |
| 19:34:37 | * | gokr quit (Quit: Leaving.) |
| 19:39:11 | * | kulelu88 joined #nim |
| 19:39:28 | kulelu88 | Does Nim have a good regex lib? |
| 19:40:23 | dom96 | kulelu88: https://nim-lang.org/docs/re.html |
| 19:41:04 | kulelu88 | ty |
| 19:41:04 | * | Jesin joined #nim |
| 19:43:29 | FromGitter | <Varriount> There's also nre |
| 19:48:07 | kulelu88 | which 1 would be recommended? |
| 19:48:16 | Araq | re |
| 19:50:15 | * | girvo joined #nim |
| 19:50:26 | kulelu88 | Araq: my goal is to use Nim to analyze large .sql files via pattern-matching |
| 19:50:42 | Araq | why not use parsesql.nim then? |
| 19:51:15 | cheatfate | kulelu88, analyzing large .sql files via pattern-matching is not a good idea |
| 19:51:50 | kulelu88 | cheatfate: what do you recommend instead? I want to match regexes against data that appears in the DB |
| 19:52:34 | cheatfate | As Araq said, use parsesql.nim and apply regexes on values |
| 19:52:45 | cheatfate | not on whole .sql file |
| 19:53:30 | cheatfate | but its also depends on your sql... because i think parsesql.nim supports only standart sql |
| 19:55:01 | * | girvo quit (Ping timeout: 268 seconds) |
| 19:56:06 | kulelu88 | does mysql data count as standard? |
| 19:58:24 | cheatfate | every database has its own sql extensions, but to be sure you need to parse it with parsesql.nim |
| 19:59:06 | cheatfate | as i see currently parsesql.nim supports ansi sql and postgresql, maybe with minor changes it can handle full mysql |
| 19:59:24 | kulelu88 | I'll give it a go :) |
| 20:03:34 | * | bjz joined #nim |
| 20:08:31 | * | libman joined #nim |
| 20:23:11 | * | Jesin quit (Quit: Leaving) |
| 20:39:43 | * | Jesin joined #nim |
| 20:43:09 | * | kulelu88 quit (Ping timeout: 260 seconds) |
| 20:43:40 | * | pie_ joined #nim |
| 20:46:09 | * | girvo joined #nim |
| 20:49:03 | * | gokr joined #nim |
| 20:49:52 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 20:52:14 | * | rokups quit (Quit: Connection closed for inactivity) |
| 21:03:12 | * | rauss quit (Quit: WeeChat 1.7) |
| 21:06:28 | * | couven92 quit (Ping timeout: 240 seconds) |
| 21:08:37 | * | vendethiel- joined #nim |
| 21:09:41 | * | rupil quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) |
| 21:10:05 | * | vendethiel quit (Ping timeout: 246 seconds) |
| 21:11:51 | * | bjz_ joined #nim |
| 21:13:17 | * | bjz_ quit (Client Quit) |
| 21:13:57 | * | bjz quit (Ping timeout: 260 seconds) |
| 21:17:37 | * | Vladar quit (Remote host closed the connection) |
| 21:19:51 | * | xet7 joined #nim |
| 21:33:10 | * | Trustable joined #nim |
| 21:54:23 | * | sz0 quit (Quit: Connection closed for inactivity) |
| 21:57:55 | * | xet7 quit (Quit: Leaving) |
| 22:06:42 | zachcarter | man linking on linux is SO broken with Nim |
| 22:06:47 | zachcarter | I guess it’s broken in general |
| 22:07:05 | zachcarter | but you literally cannot link to a lot of dynamic libraries without specifying relative paths and even then |
| 22:08:59 | zachcarter | Araq: is it possible to set / configure : https://github.com/nim-lang/Nim/blob/75345ad1aacf8e2a4d43e4e89f16f6a641d6a9c3/lib/pure/dynlib.nim#L80-L82 ? |
| 22:09:25 | zachcarter | like to set which one you want when dynamically linking? |
| 22:09:59 | zachcarter | looks like it is based on a PR I just saw, question is how |
| 22:10:13 | * | rauss joined #nim |
| 22:10:56 | demi- | zachcarter: what do you mean? |
| 22:11:17 | demi- | those are constants that are defined in the dlfcn header |
| 22:11:25 | zachcarter | https://github.com/nim-lang/Nim/pull/897/files |
| 22:11:38 | * | cheatfate quit (Read error: Connection reset by peer) |
| 22:11:56 | * | rauss quit (Client Quit) |
| 22:11:56 | zachcarter | yeah I think I need support for RTLD_LAZY |
| 22:11:57 | * | cheatfate joined #nim |
| 22:12:05 | demi- | zachcarter: i think you have a misunderstanding as to what those functions are for |
| 22:12:22 | zachcarter | perhaps |
| 22:13:17 | zachcarter | demi-: I’m reading this and facing the same / similar problem |
| 22:13:21 | demi- | there is dynamic linking, which means you supply the static linker with paths to libraries that should get loaded at runtime to satisfy the symbol requirements of your application. there are linker search paths, which tell the linker where to look to find such libraries, and there are runtime search paths that are used to search for the library when the application is being executed |
| 22:13:44 | zachcarter | https://github.com/DerelictOrg/DerelictUtil/issues/14 |
| 22:14:01 | zachcarter | I believe it’s a similar problem anyway |
| 22:14:15 | demi- | then there is dynamic loading, which is done with dlfcn, where you can load a shared library into your application's address space at runtime and then dynamically make calls against it using dladdr and dlsym |
| 22:14:25 | zachcarter | okay |
| 22:14:27 | demi- | dynamic loading and calls is not the same as dynamic linking |
| 22:14:43 | zachcarter | so I’m referring to dynamic loading not dynamic linking |
| 22:14:54 | zachcarter | my bad I didn’t realize that |
| 22:15:51 | demi- | when you load something using dlfcn, the application doesn't already know it needs to get that library loaded; thus you need to supply paths to the library you want based on what you want or where you are. |
| 22:16:25 | demi- | you should avoid dynamic loading of libraries as it is typically unsafe behavior |
| 22:17:04 | zachcarter | okay |
| 22:17:07 | demi- | the better option is to dynamically link libraries and specify where to look for it so that it can be run correctly on any given system |
| 22:17:15 | zachcarter | well that’s what I’m doing |
| 22:17:18 | zachcarter | I think |
| 22:17:52 | zachcarter | I’m specifying a relative path to the shared library I’m trying to link against |
| 22:18:09 | demi- | so you are supplying linker flags for the library search paths using -L and -l then the runtime paths using -rpath |
| 22:18:23 | * | gokr quit (Ping timeout: 240 seconds) |
| 22:18:31 | zachcarter | yes one second let me copy and paste |
| 22:19:41 | zachcarter | https://gist.github.com/zacharycarter/1ac1ad369d241c72b544db8017932d8e |
| 22:20:19 | zachcarter | so undefined symbol: glXGetFBConfigAttrib |
| 22:21:14 | zachcarter | that’s why I linked to - https://github.com/DerelictOrg/DerelictUtil/issues/14 |
| 22:21:21 | * | Nobabs27 joined #nim |
| 22:21:22 | zachcarter | the problem sounds similiar, it’s just a D issue |
| 22:22:17 | demi- | no, it is a completely different thing |
| 22:22:20 | zachcarter | I guess it’s not the same problem because he’s saying undefined symbol: bgfx_destroy_uniform |
| 22:22:21 | zachcarter | is his error |
| 22:22:22 | zachcarter | yeah |
| 22:22:54 | demi- | your issue is that the symbol you have "glXGetFBConfigAttrib" isn't defined anywhere in the libraries you link against |
| 22:23:29 | demi- | or it is at least not exposed, so you need to get versions of the libraries that expose or have a symbol with that name |
| 22:23:37 | demi- | or you need to remove that call/reference |
| 22:24:07 | zachcarter | hmm |
| 22:24:27 | zachcarter | alright I’ll try to figure that out thank you |
| 22:25:40 | * | Trustable quit (Remote host closed the connection) |
| 22:50:50 | * | rauss joined #nim |
| 22:55:00 | * | elrood quit (Quit: Leaving) |
| 23:15:49 | * | girvo quit (Ping timeout: 240 seconds) |
| 23:21:53 | bbl_ | Should I be able to store iterators inside objects? |
| 23:21:58 | * | Nobabs27 quit (Quit: Leaving) |
| 23:22:47 | bbl_ | Codegen fails with "error: duplicate label ‘STATE1’" |
| 23:25:00 | bbl_ | It seems to fail when I'm using another iterator inside :/ |
| 23:32:57 | * | girvo joined #nim |
| 23:38:47 | * | couven92 joined #nim |
| 23:40:37 | * | nsf quit (Quit: WeeChat 1.7) |
| 23:53:11 | * | derlafff quit (Ping timeout: 264 seconds) |
| 23:53:43 | * | derlafff joined #nim |
| 23:54:02 | * | arnetheduck joined #nim |