| 06:14:48 | Araq | fowl: http://nimrod-code.org/c2nim.html#def-directive |
| 06:14:57 | Araq | to get the "remove identifier" feature |
| 06:15:18 | Araq | and I don't think you can import variables from a DLL ... :-/ |
| 06:15:32 | Araq | you need to do that the hard way via |
| 06:16:14 | Araq | http://nimrod-code.org/dynlib.html |
| 08:28:28 | dom96 | good morning |
| 09:14:36 | * | SchalaZeal joined #nimrod |
| 09:16:31 | SchalaZeal | woot |
| 09:16:53 | Araq | ha good timing ;-) |
| 09:17:27 | SchalaZeal | I tried my best but const C vars are getting the finger from Nimrod |
| 09:18:10 | SchalaZeal | had to comment them out for the time being |
| 09:19:04 | Araq | I saw it, make the 'addr' expressions templates instead |
| 09:19:15 | Araq | and 'dynlib' doesn't support yet vars ... |
| 09:19:20 | Araq | but I'm working on it |
| 09:19:53 | SchalaZeal | ah ok |
| 09:20:14 | SchalaZeal | Err, how do I make addr expressions templates? |
| 09:29:27 | Araq | template constFake: expr = addr(someGlobal[1]) |
| 09:31:07 | Araq | btw c2nim now generates proper Nimrod types like 'culong' |
| 09:31:33 | SchalaZeal | I saw :D |
| 09:32:36 | Araq | so now it's true when I say: c2nim often does a better job than a human being :P |
| 09:32:36 | SchalaZeal | Although, in the case of culonglong, might want to map it to __int64 when Windows is targetted |
| 09:32:55 | Araq | you can do: |
| 09:33:02 | Araq | #mangle culonglong __int64 |
| 09:33:24 | SchalaZeal | hm |
| 09:34:29 | SchalaZeal | what's a PEG pattern, by the way? |
| 09:36:01 | Araq | a "better" regex |
| 09:36:11 | Araq | for some definition of "better" ... |
| 09:36:43 | Araq | I don't like them as much anymore as I used to ;-) |
| 09:37:14 | SchalaZeal | Regex gives me a headache when I try to learn it |
| 09:41:51 | SchalaZeal | I really can't wait for C++ interfacing to improve. I'd love to make a wxWidgets wrapper |
| 09:46:46 | SchalaZeal | or alternatively ObjC so I can do Cocoa interfacing |
| 09:48:06 | Araq | hu? |
| 09:48:15 | Araq | oh you mean c2nim support for c++? |
| 09:48:34 | SchalaZeal | well I'd like to get started on either a wxWidgets wrapper or Cocoa wrapper |
| 09:48:40 | SchalaZeal | yeah |
| 09:50:20 | Araq | wxWidgets please |
| 09:50:42 | Araq | I had some wxWidgets wrapping code btw |
| 09:50:55 | Araq | it's very old and used a C intermediate binding |
| 09:51:29 | Araq | you could also take over 'claro' |
| 09:51:40 | SchalaZeal | What's that? |
| 09:52:12 | Araq | https://github.com/Araq/Claro |
| 09:52:33 | Araq | it's a simple UI toolkit that works on mac, windows and linux |
| 09:52:41 | Araq | using cocoa, gtk and win api |
| 09:52:47 | Araq | so you get native widgets |
| 09:53:15 | Araq | I tested it with some examples and it works |
| 09:53:27 | Araq | needs cleanup though and a better nimrod interface |
| 09:53:39 | SchalaZeal | why not rewrite it in Nimrod? |
| 09:53:51 | Araq | too much work |
| 09:54:02 | SchalaZeal | hm |
| 09:54:23 | Araq | plus with the C/objective C combo you can always access the most recent headers |
| 09:54:41 | Araq | nimrod has no cocoa wrappers yet |
| 09:55:12 | SchalaZeal | Yeah but I feel if I wrap C++/ObjC, I'd have to do it by hand |
| 09:55:48 | Araq | yeah c2nim can't parse that yet |
| 09:56:01 | SchalaZeal | bummer |
| 09:56:39 | Araq | you could patch swig so that it supports nimrod |
| 09:56:41 | SchalaZeal | I'd really like to learn the internals better so I can try my luck at Java or .NET backends |
| 09:56:59 | SchalaZeal | I don't even know how to use SWIG |
| 09:57:16 | Araq | .NET backend is possible |
| 09:57:22 | Araq | just forget about Java |
| 09:57:34 | Araq | it can only be done inefficiently |
| 09:57:42 | Araq | as the JVM is a piece of crap |
| 09:58:33 | SchalaZeal | hm |
| 09:58:48 | SchalaZeal | how so? |
| 09:58:57 | SchalaZeal | I mean... not that I'd touch it |
| 09:59:30 | Araq | no support for: value based datatypes, unsigned integers, 'cast' |
| 09:59:47 | SchalaZeal | it can't even cast? |
| 09:59:50 | Araq | first class functions |
| 10:00:10 | SchalaZeal | first class functions? what are they? |
| 10:00:23 | Araq | "pointer to function" (roughly) |
| 10:01:01 | Araq | it really only supports java ... |
| 10:01:13 | SchalaZeal | it? |
| 10:01:30 | SchalaZeal | oh the uhm |
| 10:02:01 | SchalaZeal | well, Oracle's only gonna teabag it further I think |
| 10:05:00 | SchalaZeal | C++ I would use but the compiling is dreadful, C# I really like but it doesn't recognize \0, \1, etc and if you want to use a different library based on the host system, you're screwed |
| 10:07:59 | SchalaZeal | compiling in C is dreadful because you have to specify not only dependencies, but dependencies of dependencies |
| 10:08:36 | SchalaZeal | take for example wxWidgets.... it's a slew of dependencies |
| 10:11:32 | SchalaZeal | One of the reasons why I hate static libraries... \ |
| 10:12:04 | Araq | well yeah, wxwidgets is not nice |
| 10:12:50 | SchalaZeal | C/C++ isn't nice |
| 10:14:01 | SchalaZeal | you'd figure if the dependencies had info on their own dependencies, they could just implicitly link them like Nimrod does |
| 10:15:23 | Araq | but then you'd have to admit that there is a problem |
| 10:15:55 | SchalaZeal | hm |
| 10:16:10 | Araq | people instead pretend that autoconf works ;-) |
| 10:17:16 | SchalaZeal | CMake is more my thing... but their FindWX module is fussy about wx-config's presence or not |
| 10:21:17 | SchalaZeal | Well, 3:20 AM here... guess I'll do a Claro wrapper tomorrow |
| 10:22:00 | SchalaZeal | as for working on the actual library....... as I said, algorithms are my weakness |
| 10:22:34 | Araq | but the claro wrapper already exists |
| 10:22:51 | SchalaZeal | oh |
| 10:22:54 | Araq | it just needs a more nimrodic interface on top of that |
| 10:22:58 | SchalaZeal | I... didn't see it |
| 10:23:01 | Araq | and more examples |
| 10:23:04 | Araq | and more docs |
| 10:23:13 | Araq | and somebody who tests it |
| 10:24:12 | SchalaZeal | I guess I could try in testing/examples |
| 10:25:08 | SchalaZeal | yeah, looking over the wrapper, I think I could definately use this |
| 10:25:41 | SchalaZeal | maybe an impure module that exposes it in a friendlier manner |
| 10:27:10 | Araq | yeah and make the callback system use closures :-) |
| 10:27:40 | SchalaZeal | Closures I still need to grasp myself... heh |
| 10:31:19 | SchalaZeal | ick.....SCons.... I'm terrible with that |
| 10:33:32 | Araq | hey, it doesn't use scons anymore |
| 10:34:44 | SchalaZeal | good heh |
| 10:35:02 | SchalaZeal | well, see you later... going to bed |
| 10:35:37 | * | SchalaZeal quit () |
| 13:01:58 | zahary | Araq, I've ran into a problem with dynamic libs. during initialization, some functions from nimRtl are called before they are loaded which leads to crashes |
| 13:02:27 | zahary | for example the first line in NimMain is initStackBottom(); which is supposed to come from nimRtl, but won't be loaded until systemInit() |
| 13:04:03 | zahary | should I move the library loading code in nim_datInit() and have this at the first line in NimMain - this sounds the most sane fix to me |
| 13:41:14 | zahary | it would be nice to add support for the more traditional style of dynamic linking to nimRtl too (e.g. where dependency walkers and other tools will see the dependency) - I can add another define for that |
| 13:43:56 | * | fowl quit (Ping timeout: 248 seconds) |
| 13:48:39 | * | Trix[a]r_za is now known as Trixar_za |
| 14:31:08 | Araq | zahary: I'm puzzled why the test suite did not detect this |
| 14:33:51 | zahary | where were the dynlib tests? I can look at the compiled sources to see what's different there |
| 14:34:20 | Araq | tests/specials.nim, runDLLTests |
| 14:35:55 | Araq | apparently they are not run |
| 14:36:07 | Araq | from koch |
| 14:37:40 | Araq | and I know what's different |
| 14:37:57 | Araq | I changed the setStackBottom initialization |
| 14:38:11 | Araq | as sometimes it would miss 16 bytes or so |
| 14:38:21 | zahary | yeah, I noticed |
| 14:38:28 | zahary | what about the proposed fix? |
| 14:38:53 | Araq | dunno, sounds bad to have it in another stack frame |
| 14:38:58 | zahary | my reasoning is that it's dangerous to call systemInit before setStackBottom, because we may introduce a GC call there (unlikely tho) |
| 14:39:05 | zahary | and nimdat is safer in this regard |
| 14:39:20 | Araq | nimdat is a call from NimMain |
| 14:39:32 | Araq | and as such is likely to reintroduce the bug |
| 14:39:53 | Araq | that I fixed by moving setStackBottom to NimMain() |
| 14:40:02 | zahary | which bug? the incorrect stack bottom bug? |
| 14:40:05 | Araq | yes |
| 14:40:54 | zahary | I don't want to move setStackBottom - it will remain in NimMain, but it will be on the second line after the nimdat call, where dynamic libraries were loaded |
| 14:41:28 | Araq | ah I see |
| 14:41:44 | Araq | speaking of which |
| 14:41:56 | Araq | how come that masking the stack bottom to a page boundary does not work? |
| 14:42:16 | Araq | that would make this code way less fragile |
| 14:42:28 | Araq | somehow it doesn't work ... |
| 14:43:57 | zahary | well, what do you mean by "doesn't work" here? I guess it computes the masked address, but it fails in some other way? |
| 14:44:36 | dom96 | Araq: I had this idea... would it be possible to convert a regex pattern to a pegs pattern? |
| 14:44:37 | Araq | well it didn't fix the bug |
| 14:45:00 | Araq | dom96: yes for a subset of regexes, in general it's not possible |
| 14:45:11 | zahary | dom96, not always - the biggest difference is that peg patterns are always greedy |
| 14:45:30 | dom96 | oh. Pity. |
| 14:46:26 | Araq | hrm nim__datInit could call the GC |
| 14:46:35 | Araq | or maybe not |
| 14:46:37 | zahary | hmm, how? |
| 14:46:44 | Araq | dunno :-) |
| 14:46:54 | Araq | I guess it's safe |
| 14:46:56 | zahary | it's just setting values in the data section there, right? |
| 14:47:21 | Araq | I think it set someting else too but can't remember :D |
| 14:47:34 | Araq | well ... we'll see about that |
| 14:47:39 | Araq | your fix sounds good |
| 14:47:57 | Araq | runDLLTests(r, options) is disabled in specials.nim |
| 14:48:23 | Araq | I suppose I disabled it because the test machines never set LD_LIBRARY_PATH |
| 14:48:30 | Araq | and thus it would fail anyway |
| 14:48:48 | Araq | which is annoying |
| 14:49:38 | zahary | btw, nimrod probably doesn't support the so called "rpath" in mac executables, which indicates in which directories to look for libraries? |
| 14:50:52 | Araq | never heard of it, so no ... :-) |
| 14:52:52 | zahary | I'm a bit annoyed by the details of shipping dynamic libraries on mac - problem is, you're supposed to keep them in some weird adjacent directories |
| 14:52:53 | zahary | http://www.mikeash.com/pyblog/friday-qa-2009-11-06-linking-and-install-names.html |
| 14:54:02 | zahary | also, http://en.wikipedia.org/wiki/Rpath |
| 14:55:55 | Araq | it's only sane on windows IMHO |
| 14:56:29 | Araq | LD_LIBRARY_PATH has obviously never been designed with testing in mind |
| 14:56:52 | Araq | and of course on macosx they have 2+ different ways |
| 14:57:00 | Araq | as they never got rid of the unix cruft |
| 15:03:57 | Araq | btw I noticed that compile times of nim__dat.c are pretty bad |
| 15:04:10 | Araq | especially if you use symbol files |
| 15:04:32 | Araq | as this requires the compiler to merge multiple nim__dat.c files ... |
| 15:04:42 | Araq | I wonder what we can do to prevent that |
| 15:09:54 | Araq | see you later |
| 16:01:35 | * | Zerathul joined #nimrod |
| 16:03:08 | * | Zerathul quit (Client Quit) |
| 16:48:14 | * | Zerathul joined #nimrod |
| 18:48:48 | * | Trixar_za is now known as Trix[a]r_za |
| 20:20:30 | * | fowl joined #nimrod |
| 21:17:27 | * | Zerathul quit (Ping timeout: 255 seconds) |
| 21:41:05 | * | pmros joined #nimrod |
| 21:42:15 | dom96 | hello pmros |
| 21:42:27 | pmros | hello |
| 21:47:19 | Araq | hi pmros |
| 21:47:25 | pmros | dom96, have you written a kernel in nimrod? |
| 21:47:30 | pmros | hi, Araq |
| 21:47:43 | pmros | I wanna see it! |
| 21:48:35 | dom96 | pmros: It's not as good as you think. It barely shows text. |
| 21:48:45 | dom96 | And I need to go to sleep right now. |
| 21:48:57 | pmros | it's enough for me |
| 21:49:10 | dom96 | I'll put it on github later. See ya later. |
| 21:49:11 | pmros | kernel bare bone |
| 21:49:26 | pmros | ok |
| 21:49:30 | pmros | thanks |
| 21:49:53 | pmros | i'm excited |
| 21:50:35 | pmros | i've to go |
| 21:50:42 | Araq | alright bye |
| 21:50:47 | pmros | see you! |
| 21:50:57 | * | pmros quit (Quit: Saliendo) |