00:01:34 | * | johnsoft quit (Read error: Connection reset by peer) |
00:02:26 | * | johnsoft joined #nimrod |
00:05:16 | Jehan_ | Okay, I've got it. |
00:13:20 | Araq | great. |
00:13:31 | Araq | but I need to sleep now, see you tomorrow |
00:14:19 | Jehan_ | Okay, will push once I've tested more. |
00:24:30 | * | johnsoft quit (Read error: Connection reset by peer) |
00:32:13 | adoniscik | I need to pass matrices to a library I'm wrapping. I discovered that nimrod does not treat nested arrays the same as "unrolled" ones, be it row major or column major. I thought they were the same thing internally so it would make no difference |
00:35:49 | * | ARCADIVS quit (Quit: WeeChat 0.4.3) |
00:40:20 | * | johnsoft joined #nimrod |
00:42:20 | * | EXetoC quit (Quit: WeeChat 0.4.3) |
00:44:03 | NimBot | Araq/Nimrod devel a772105 Reimer Behrends [+0 ±2 -0]: Fixed stack bottom initialization for DLLs. |
00:44:03 | NimBot | Araq/Nimrod devel fe3d9dd Andreas Rumpf [+0 ±2 -0]: Merge pull request #1480 from rbehrends/fix-stackscan2... 2 more lines |
00:45:27 | Araq | adoniscik: they are the same afaict. unless you mean 'seq', not 'array' |
00:48:05 | adoniscik | no, I don't. I should add that I used the following dereferencing operator, suggested by someone here: template `&:`*(x: expr): expr = cast[ptr type(x[0])](addr x) |
00:48:32 | adoniscik | perhaps it's the x[0] part ? |
00:48:46 | adoniscik | if so, how should I generalize it? |
00:49:12 | NimBot | Araq/Nimrod devel af0de90 Araq [+0 ±1 -0]: fixes #1475 |
00:49:12 | NimBot | Araq/Nimrod devel f3d530e Araq [+1 ±6 -0]: fixes #1434 |
00:49:12 | NimBot | Araq/Nimrod devel 27b9d10 Araq [+0 ±3 -1]: Merge branch 'devel' of https://github.com/Araq/Nimrod into devel |
00:49:12 | NimBot | Araq/Nimrod devel 2728bbc Araq [+0 ±4 -0]: fixes newly introduced bugs |
00:49:12 | NimBot | 2 more commits. |
00:49:24 | adoniscik | x[0][0] if type(array) else x[0] or something like that? |
00:49:49 | Araq | there is a codegen bug affecting addr and arrays |
00:49:55 | Araq | maybe that's your problem |
00:57:09 | Araq | def-: please look into https://github.com/Araq/Nimrod/issues/1449 |
00:59:29 | Skrylar | oh my gibbus. i just thought about touching a nimrod file with emacs, and discovered that emacs has a very strange idea of how "please indent by this much" means without a custom mode |
01:02:14 | Araq | emacs uses tabs to compress the file size |
01:02:24 | Araq | it's incredibly stupid |
01:04:57 | Skrylar | pff. i'm one of those tab-indenters :P |
01:05:52 | Skrylar | the notion of overriding ANSI tab to be the "please indent" marker, and then using spaces for any post-indentation adjustments, actually does have merit (it lets someone choose their own indent level for themselves); its just not done because most people use idiot text editors |
01:06:46 | Skrylar | even better is the elastic tabstop suggestion, which is implemented by exactly zero editors. lol |
01:13:32 | Jehan_ | Elastic tabstop? |
01:14:28 | Skrylar | Jehan_: its a concept where it treats each tab as going to a different tabstop, which are stretched based on the previous line; so the first tab aligns with the first tab on the previous, and the second tab etc |
01:14:42 | Skrylar | so basically you can have one tab for indent, the second for shoving comments off to the side |
01:15:15 | Skrylar | it does a better job of making tables in ascii because you don't have to insert one every 8-pieces, you just insert ONE and it does what you mean |
01:15:26 | * | saml_ joined #nimrod |
01:17:13 | Jehan_ | Gotcha. |
01:17:22 | def- | Araq: tomorrow probably |
01:21:34 | NimBot | Araq/Nimrod devel 8f5bf06 Araq [+0 ±1 -0]: fixes #1450 |
01:21:34 | NimBot | Araq/Nimrod devel 65587f7 Araq [+0 ±1 -0]: fixes #1433 |
01:31:39 | NimBot | Araq/Nimrod devel 1a7be4c Araq [+0 ±1 -0]: fixes #722 |
01:37:04 | * | q66 quit (Quit: Leaving) |
01:42:17 | * | brson quit (Quit: leaving) |
01:45:23 | * | adoniscik quit (Ping timeout: 260 seconds) |
01:45:28 | * | Jesin quit (Quit: Leaving) |
01:55:05 | * | Jesin joined #nimrod |
02:14:04 | * | willw946 quit (Ping timeout: 260 seconds) |
02:23:36 | * | Jehan_ quit (Quit: Leaving) |
02:43:46 | * | xenagi joined #nimrod |
03:06:04 | * | endou__ quit (Ping timeout: 240 seconds) |
03:06:26 | * | endou__ joined #nimrod |
03:06:57 | * | darkf_ joined #nimrod |
03:08:17 | * | darkf quit (Ping timeout: 260 seconds) |
03:43:07 | * | darkf_ is now known as darkf |
03:49:54 | * | zling__ joined #nimrod |
03:49:55 | * | jez0990 joined #nimrod |
03:49:56 | * | TylerE_ joined #nimrod |
03:52:33 | * | dom96_ joined #nimrod |
03:52:38 | * | Zuchto_ joined #nimrod |
03:52:44 | * | zling_ quit (Ping timeout: 250 seconds) |
03:52:44 | * | Trixar_za quit (Ping timeout: 250 seconds) |
03:52:44 | * | dom96 quit (Ping timeout: 250 seconds) |
03:52:45 | * | TylerE quit (Ping timeout: 250 seconds) |
03:52:45 | * | Zuchto quit (Ping timeout: 250 seconds) |
03:52:45 | * | Araq quit (Ping timeout: 250 seconds) |
03:52:46 | * | johnsoft quit (Ping timeout: 250 seconds) |
03:52:47 | * | jez0990_ quit (Ping timeout: 250 seconds) |
03:52:47 | * | eigenlicht quit (Ping timeout: 250 seconds) |
03:52:47 | * | Amrykid quit (Ping timeout: 250 seconds) |
03:52:48 | * | johnsoft joined #nimrod |
03:52:48 | * | Zuchto_ is now known as Zuchto |
03:52:59 | * | Trixar_za joined #nimrod |
03:53:50 | * | dom96_ is now known as dom96 |
03:53:53 | * | Araq_bnc joined #nimrod |
03:53:56 | * | eigenlicht joined #nimrod |
03:54:02 | * | dom96 quit (Changing host) |
03:54:02 | * | dom96 joined #nimrod |
03:54:05 | * | TylerE_ is now known as TylerE |
03:54:32 | * | Amrykid joined #nimrod |
03:58:24 | * | reactormonk quit (Ping timeout: 250 seconds) |
04:01:57 | * | saml_ quit (Quit: Leaving) |
04:02:35 | * | reactormonk joined #nimrod |
04:07:16 | * | Trixar_za quit (Ping timeout: 250 seconds) |
04:07:16 | * | johnsoft quit (Ping timeout: 250 seconds) |
04:07:16 | * | Trixar_za joined #nimrod |
04:07:27 | * | johnsoft joined #nimrod |
04:14:36 | * | adoniscik joined #nimrod |
04:16:52 | * | xenagi quit (Quit: Leaving) |
04:19:03 | * | flaviu quit (Ping timeout: 240 seconds) |
04:38:50 | * | johnsoft quit (Ping timeout: 272 seconds) |
05:00:31 | Varriount | Araq_bnc, dom96: I have the new filewatch implementation about halfway done - right now I'm working around some bugs. Right now the new implementation has about 100kb less overhead |
05:02:32 | Skrylar | yay efficiency |
05:03:25 | Varriount | Skrylar: It's probably due to less pointers. The old implementation used a recursive technique to simulate file-level event monitoring |
05:10:39 | * | seubert_ joined #nimrod |
05:10:59 | * | seubert quit (Write error: Broken pipe) |
05:16:57 | Skrylar | Varriount: needs more pointers. write it all in lisp and cover the ocean in cons structures. xD |
05:17:50 | Varriount | Skrylar: Reminds me of http://grooveshark.com/s/Sea+Of+Simulation/4DLQjw?src=5 |
05:23:28 | Varriount | Yay! No memory leak! |
05:33:52 | * | johnsoft joined #nimrod |
05:36:49 | * | johnsoft quit (Read error: Connection reset by peer) |
05:37:29 | * | johnsoft joined #nimrod |
05:48:54 | Skrylar | Varriount: poor memory leaks, always getting persecuted |
05:49:21 | * | darkf_ joined #nimrod |
05:50:12 | * | darkf quit (Ping timeout: 250 seconds) |
05:51:05 | * | darkf_ is now known as darkf |
05:55:31 | Skrylar | i'm looking forward to being done with this msgpack serializer :/ |
05:57:48 | Skrylar | Varriount: i see now that the GUI programmers were telling the truth when they said that GUI coding is less tedious |
05:58:11 | Skrylar | people care way more about a couple of broken command buttons than finely tuned infrastructure |
05:58:22 | * | darkf_ joined #nimrod |
05:59:42 | * | darkf quit (Ping timeout: 260 seconds) |
06:00:56 | adoniscik | I have a problem with templates. Can anyone tell me why the template mistakenly follows the else path here? http://pastebin.com/40W4J11Q |
06:00:59 | * | darkf_ is now known as darkf |
06:05:05 | * | darkf_ joined #nimrod |
06:05:46 | * | darkf quit (Ping timeout: 260 seconds) |
06:05:50 | * | darkf_ is now known as darkf |
06:08:06 | * | adoniscik left #nimrod ("Leaving") |
06:08:12 | * | adoniscik joined #nimrod |
06:11:42 | adoniscik | got it! it's the if statement. I don't see why we need to use when if they serve the same purpose, though. |
06:13:02 | * | nande quit (Read error: Connection reset by peer) |
06:20:51 | * | bogen joined #nimrod |
06:37:57 | adoniscik | false alarm, it's still broken. Now it fails to fall through the else when the argument is not a nested array |
06:38:15 | adoniscik | after changing the if to a when, that is |
06:48:36 | adoniscik | okay, fixed that too. so it was when after all :) |
07:03:40 | * | Araq_bnc is now known as Araq |
07:16:26 | NimBot | Araq/Nimrod devel d59b9a2 Reimer Behrends [+0 ±1 -0]: Fix stack bottom initialization for non-main modules.... 5 more lines |
07:16:26 | NimBot | Araq/Nimrod devel d8f6a2a Andreas Rumpf [+0 ±1 -0]: Merge pull request #1481 from rbehrends/fix-stackscan2... 2 more lines |
07:21:26 | * | darkf_ joined #nimrod |
07:23:32 | * | darkf quit (Ping timeout: 240 seconds) |
07:31:17 | * | io2 joined #nimrod |
07:31:19 | * | Jehan_ joined #nimrod |
07:35:07 | * | ome joined #nimrod |
07:51:16 | * | kunev joined #nimrod |
07:53:34 | * | willwillson joined #nimrod |
07:55:19 | * | adoniscik quit (Ping timeout: 255 seconds) |
07:59:40 | * | Jehan_ quit (Quit: Leaving) |
08:17:33 | * | willwillson quit (Ping timeout: 240 seconds) |
08:24:07 | * | darkf_ is now known as darkf |
08:44:09 | * | zahary_ joined #nimrod |
09:01:07 | * | Zuchto left #nimrod (#nimrod) |
09:06:59 | * | q66 joined #nimrod |
10:33:43 | * | nequitans_ quit (Ping timeout: 255 seconds) |
10:52:25 | * | ARCADIVS joined #nimrod |
12:26:28 | * | darkf quit (Quit: Leaving) |
12:48:33 | * | EXetoC joined #nimrod |
13:22:34 | * | zahary_ quit (Read error: Connection reset by peer) |
13:24:39 | * | zahary_ joined #nimrod |
13:49:30 | * | rbenit68 joined #nimrod |
13:51:39 | rbenit68 | list |
13:51:53 | * | rbenit68 quit (Client Quit) |
13:53:43 | * | seubert_ is now known as seubert |
14:00:35 | * | bogen quit (Quit: Leaving.) |
14:00:48 | * | io2 quit (Quit: ...take irc away, what are you? genius, billionaire, playboy, philanthropist) |
14:09:47 | * | askatasuna joined #nimrod |
14:16:45 | * | Jesin quit (Quit: Leaving) |
14:20:17 | * | willwillson joined #nimrod |
14:27:24 | * | Jesin joined #nimrod |
14:44:30 | * | willwillson quit (Ping timeout: 250 seconds) |
14:50:18 | * | willwillson joined #nimrod |
15:16:59 | * | gsingh93 joined #nimrod |
15:36:03 | * | EXetoC1 joined #nimrod |
15:38:41 | * | EXetoC quit (Quit: WeeChat 0.4.3) |
15:40:14 | * | EXetoC1 is now known as EXetoC |
16:08:14 | * | Matthias247 joined #nimrod |
16:27:21 | * | kunev quit (Quit: leaving) |
16:38:12 | * | adoniscik joined #nimrod |
16:38:19 | * | shodan45 quit (Quit: Konversation terminated!) |
16:42:30 | * | nequitans joined #nimrod |
16:54:46 | * | Demos joined #nimrod |
16:58:34 | * | brson joined #nimrod |
17:00:43 | * | io2 joined #nimrod |
17:02:29 | * | askatasuna quit (Read error: Connection reset by peer) |
17:09:28 | * | icebattle joined #nimrod |
17:36:28 | * | Matthias247 quit (Read error: Connection reset by peer) |
17:37:32 | * | ARCADIVS quit (Quit: WeeChat 0.4.3) |
18:00:54 | * | brson quit (Quit: leaving) |
18:01:02 | * | brson joined #nimrod |
18:03:45 | NimBot | Araq/Nimrod devel bd32255 Dominik Picheta [+0 ±1 -0]: Fixes #1158. |
18:17:49 | Demos | http://mollyrocket.com/casey/stream_0029.html |
18:17:57 | Demos | not nimrod, but programming and API design |
18:18:05 | Demos | a good windows API bash is good for the soul |
18:23:27 | EXetoC | Araq: was that a "no" to everything, including symbol exclusion when importing? though I guess the initial focus was on the syntax |
18:26:10 | Araq | EXetoC: well it's a "no" for version 1 and a "ugh, this tree structure looks too complex" for version 1.x |
18:26:52 | Araq | sorry ... there are so many bug reports that it's depressing me and so I'm aggressively closing issues |
18:27:28 | EXetoC | that's fine. I might specifically address exclusion and renaming in a couple of months |
18:35:58 | * | nequitans quit (Remote host closed the connection) |
18:47:48 | EXetoC | maybe I should have a look at that type class bug again, but with a debugger this time because it was impossible to make sense of anything without one |
18:48:09 | * | tdc joined #nimrod |
18:50:44 | Araq | on the contrary |
18:50:45 | * | tdc quit (Client Quit) |
18:51:22 | Demos | https://github.com/ocornut/imgui we should get this wrapped! |
18:51:25 | Araq | a debugger is either slow and broken (endb ...) or doesn't support the compiler's datatypes properly (gdb) |
18:52:09 | Araq | I always debug with 'echo' + renderTree, typeToString, debug() etc. |
18:52:51 | Demos | I use Visual Studio or windbg |
18:53:06 | Demos | although debugging typeclasses could be a problem |
18:54:06 | Araq | hmm I should really try Visual Nimrod |
18:55:37 | Demos | it works OK, I am using it. Completions are a bit slow, but at least they are async. Honestly they are faster than VS completions for even a small c++ project |
18:55:52 | EXetoC | that didn't help at all in most cases. I guess I won't bother |
18:57:04 | Demos | https://mollyrocket.com/861 interesting lecture on UI APIs |
18:57:37 | * | Ven joined #nimrod |
18:58:49 | Araq | hi Ven |
18:59:09 | EXetoC | though you weren't able to help back then, but it was a long and painful process with little progress |
18:59:39 | Ven | hi Araq :o) |
18:59:51 | Araq | Demos: perhaps we should wrap this, but we need to get this "whitestag" project to work |
19:00:25 | Demos | I dont know what that is |
19:03:50 | Araq | some textmode UI written in nimrod, I think |
19:04:26 | Demos | imGUI seems to be C++, but as far as I can tell it does not use virtual functions, and it uses few nonstatic member functions |
19:04:35 | Demos | it would have been nice if it were written in C though |
19:05:14 | Araq | you can always try c2nim in C++ mode ... |
19:05:40 | Araq | as long as nobody uses it, its bugs won't be fixed |
19:05:56 | Demos | does that output code that can be compiled with nimrod c? |
19:06:28 | Araq | er ... no |
19:06:47 | Araq | we really need module specific c++ code generation |
19:07:00 | Araq | and then it wouldn't be a problem |
19:07:42 | Araq | this is easy to do, the codegen already is shared for all the C-like targets |
19:07:45 | Demos | that particular library could probably be converted to C, or at least almost C |
19:08:45 | Demos | it does reimplement std::vector because gamedevs fear the stl |
19:09:52 | Araq | some big company had an open source STL replacement for gaming |
19:10:00 | Araq | too bad nobody uses it |
19:10:06 | EXetoC | well it still seems to rely on pointer/length inputs |
19:10:43 | Demos | I think eastl was not really that great |
19:10:57 | Demos | the stl is fine these days imo, barring bad implementations |
19:11:17 | EXetoC | static void ImImpl_RenderDrawLists(ImDrawList** const cmd_lists, int cmd_lists_count) |
19:11:44 | Demos | EXetoC, yeah. I am not sure if they take vectors as their parameters |
19:12:00 | Demos | probably not, considering that they implemented their own and nobody else will use that particular one |
19:17:06 | Demos | their rationale for making their own vector is that microsoft's (dinkumware) is quite slow in debug mode |
19:17:28 | Demos | it does a lot of iterator invalidation checks and the fact MS turns off NRVO in debug mode really does not help |
19:29:59 | * | def- quit (Ping timeout: 255 seconds) |
19:33:32 | dom96 | I created a 0.9.6 milestone. Would be awesome if you guys could help. 68 issues is a lot to get done by the end of September: https://github.com/Araq/Nimrod/milestones/0.9.6 |
19:34:54 | Araq | well looking at the list I can easily fix 10 today |
19:35:06 | dom96 | great |
19:35:20 | dom96 | Maybe you should focus on the difficult ones though? |
19:35:32 | dom96 | Give us inexperienced people a chance to fix something easy? :P |
19:35:45 | Araq | nothing is easy for you :P |
19:35:54 | dom96 | :'( |
19:36:19 | dom96 | I'll just go play some video games then. |
19:39:49 | * | flaviu joined #nimrod |
19:39:59 | Araq | well I don't know what to do anymore |
19:40:29 | Araq | I explain how the compiler works in detail to all sorts of people |
19:42:16 | Araq | but all I get are complaints that it's not documented enough |
19:42:41 | dom96 | I wasn't complaining, so what gives? |
19:42:45 | dom96 | Why insult me? |
19:43:00 | Araq | it was a general 'you', not a personal 'you' |
19:43:18 | Araq | english sucks, in german it's not as ambiguous |
19:43:28 | dom96 | Right. |
19:44:51 | EXetoC | you can always qualify with an additional word |
19:52:09 | * | untitaker quit (Ping timeout: 246 seconds) |
19:55:13 | flaviu | ya'll if you want to sound southern |
19:57:34 | * | ome quit (Quit: Connection closed for inactivity) |
19:57:46 | Araq | flaviu: is https://github.com/Araq/Nimrod/issues/652 still an issue? |
19:58:50 | Araq | I have no idea what the guy is talking about |
19:59:12 | * | untitaker joined #nimrod |
19:59:16 | flaviu | I'm not sure either, some example code would be great |
20:00:44 | flaviu | Well, I asked him for a test case |
20:01:01 | Araq | well the link has a test case, kind of |
20:03:06 | Araq | it's a perfect example of how these unix/gcc people don't give a shit about their users. and yet I'm sure this GCC behaviour is correct according to some "spec" that nobody knows about. |
20:03:58 | Araq | "d'oh! obviously the -l order matters when invoking the linker! how can you not know about that?" |
20:04:40 | Araq | "the fact that we accepted this for decades doesn't mean anything" |
20:04:48 | flaviu | GCC doesn't have a spec |
20:05:28 | flaviu | Just leave it up, if he doesn't respond in a month, just close it |
20:06:05 | Araq | well we can easily hack the compiler so that -l comes at the end of the linker invokation |
20:07:26 | flaviu | If the fix is easy, I don't see any reason to not do it. |
20:07:50 | Araq | well I dunno, it's a hack |
20:08:00 | Araq | when you do --passL:"-lfoo" |
20:08:25 | Araq | I don't want the compiler to look at what's inside the string, it should be passed to the linker as is |
20:12:10 | flaviu | hmm, yeah, hacks are bad |
20:12:28 | flaviu | Doesn't --passL just append it to the linker compiler options? That would work |
20:12:37 | flaviu | s/compiler// |
20:12:46 | Araq | I think so |
20:13:29 | Araq | yes |
20:13:37 | Araq | extccomp.addLinkOption |
20:27:10 | NimBot | Araq/Nimrod devel 06ad50b Araq [+0 ±1 -0]: fixes #669 |
20:27:10 | NimBot | Araq/Nimrod devel 4ab56d6 Araq [+0 ±4 -0]: some minor fixes |
20:27:10 | NimBot | Araq/Nimrod devel f70b35b Araq [+0 ±2 -0]: Merge branch 'devel' of https://github.com/Araq/Nimrod into devel |
20:37:02 | * | brson quit (Ping timeout: 260 seconds) |
20:40:30 | * | brson joined #nimrod |
20:42:59 | Varriount | Meeeeep |
20:49:32 | EXetoC | beep |
20:51:34 | EXetoC | Varriount: you a pro compiler developer yet? |
20:52:02 | Varriount | EXetoC: No. Just a lowly standard library developer. :/ |
20:58:26 | Demos | I know there is a way to cajole gcc into linking something without fucking about wtih adding lib and a and whatnot |
20:59:58 | Varriount | Demos: There may be a way, but gcc doesn't want you to know about it. |
21:00:37 | Demos | gcc intends to munge your input strings as much as it can and feed them to the FSF overlords :D |
21:00:52 | Demos | seriously though, gcc is pretty decent |
21:03:07 | Varriount | Demos: Oh, today I found out windows has a "natural language option" for searches |
21:03:47 | Varriount | You can type in things like "name foo" and get all files with 'foo' in the name. |
21:06:34 | Araq | dom96: whitestag\persister.exe works for me now with the libfreetype-6.dll |
21:06:56 | Demos | yeah, the windows search functionality is pretty good |
21:07:21 | Demos | I think you can do stuff like search for "xl" and get excel |
21:07:22 | Araq | dom96: what doesn't work for you? |
21:07:48 | dom96 | Araq: Re-read the guys instructions. |
21:15:06 | Araq | ok, crashes now for me too |
21:26:40 | Varriount | dom96: Ping |
21:27:01 | dom96 | yes? |
21:27:21 | * | def- joined #nimrod |
21:28:17 | Varriount | dom96: I don't suppose there's an easy way to prevent the overlapped structures my procedure allocates from being GC_unref'd when asyncdispatch runs a callback? |
21:35:31 | * | EXetoC quit (Quit: WeeChat 0.4.3) |
21:37:08 | * | def- quit (Ping timeout: 240 seconds) |
21:42:12 | * | EXetoC joined #nimrod |
21:42:46 | Varriount | dom96, Araq: I have a tentatively working implementation of file-level event monitoring in nimrod. It no longer appears to leak memory, and the overhead has been minimized. |
21:43:00 | Araq | Varriount: excellent |
21:43:25 | Varriount | All the remains to be done is actually filtering events to the user-supplied callback, and cleaning up the code. |
21:43:46 | dom96 | Varriount: You should know by the return code whether any callbacks will be run. So no. |
21:44:19 | Varriount | dom96: Wait, what? |
21:47:46 | * | Matthias247 joined #nimrod |
21:49:13 | * | noam quit (Ping timeout: 260 seconds) |
22:11:53 | * | eigenlicht quit (Ping timeout: 244 seconds) |
22:15:26 | * | eigenlicht joined #nimrod |
22:16:02 | * | Ven quit (Ping timeout: 245 seconds) |
22:33:03 | * | io2 quit (Quit: ...take irc away, what are you? genius, billionaire, playboy, philanthropist) |
22:34:14 | * | def- joined #nimrod |
22:39:36 | * | Matthias247 quit (Read error: Connection reset by peer) |
23:00:21 | * | willwillson quit (Ping timeout: 240 seconds) |
23:03:57 | * | nande joined #nimrod |
23:07:10 | * | darkf joined #nimrod |
23:08:28 | adoniscik | how can you check whether a symbol is defined in a library? I used readelf and got R_X86_64_PLT32 for the symbol in the static library and R_X86_64_JUMP_SLOT in the dynamic version. |
23:22:45 | * | flaviu quit (Remote host closed the connection) |
23:24:25 | * | flaviu joined #nimrod |
23:24:34 | dom96 | adoniscik: You would need to use dynlib I think |
23:26:57 | * | saml_ joined #nimrod |
23:28:20 | adoniscik | --dynlibOverride:foo --passL:/path/foo works but so does -l:"/path/foo" so I don't see the point; they generate the same code. |
23:53:26 | * | EXetoC quit (Remote host closed the connection) |