<< 23-09-2014 >>
00:17:02flaviu1bob_: You'll enjoy http://nimrod-lang.org/theindex.html
00:20:49*xenagi joined #nimrod
00:43:14*francisl quit (Quit: francisl)
00:54:11*brson quit (Quit: leaving)
01:04:42*q66 quit (Quit: Leaving)
01:44:30*nande joined #nimrod
01:52:47*xenagi|2 joined #nimrod
01:54:28*xenagi|2 quit (Read error: Connection reset by peer)
01:54:46*xenagi|2 joined #nimrod
01:55:37*xenagi quit (Ping timeout: 260 seconds)
01:57:32*xenagi|2 quit (Client Quit)
02:06:00*bjz quit (Ping timeout: 244 seconds)
02:31:19*phobophilos joined #nimrod
02:39:49*francisl joined #nimrod
02:42:17*fowl quit (Ping timeout: 260 seconds)
02:51:36*bogen left #nimrod (#nimrod)
02:53:04*francisl quit (Quit: francisl)
02:56:02*flaviu1 quit (Ping timeout: 245 seconds)
03:08:59*flaviu1 joined #nimrod
03:12:30*bob_ quit (Quit: Page closed)
03:39:17*Donohue joined #nimrod
03:39:21*Donohue left #nimrod ("Leaving")
03:40:11*flaviu1 quit (Ping timeout: 272 seconds)
04:54:41*ehaliewicz joined #nimrod
05:06:18*wkoch1 joined #nimrod
05:06:56*wkoch quit (Ping timeout: 260 seconds)
05:35:33*wkoch1 quit (Quit: wkoch1)
05:42:54*nande quit (Remote host closed the connection)
06:34:04*kshlm joined #nimrod
06:56:00*perturbation joined #nimrod
06:58:38perturbationare anonymous procedures inherently un-GC safe?
06:59:26reactormonkperturbation, nope
06:59:51reactormonk... I hope so, at least. I wouldn't see any connection between the two.
07:00:34*BlaXpirit joined #nimrod
07:04:35perturbationme neither :) ... I think after e6d17e62731a (https://github.com/Araq/Nimrod/commit/e6d17e62731a05110e464854eda79e891aaf2ff5) in asyncio.nim there are some problems with aporia's handleAccept
07:05:22perturbationand doing the dumb thing (just adding a {.gcsafe, closure} pragma to resolve the type error) has the compiler complain that the anonymous proc isn't GC-safe
07:05:46perturbationI'll have to bother dom96 when he's back (or just open an issue on github for Aporia)
07:11:00perturbationhmmm... think it's because it's accessing a global variable, but refactoring is beyond me
07:11:34perturbationdoing the *really* dumb thing (compiling with --threadanalysis:off) gets it to compile but I think that's cheating
07:12:10reactormonknah, that's not going to the doctor because your leg hurts
07:14:00*francisl joined #nimrod
07:19:19*francisl quit (Ping timeout: 272 seconds)
07:25:57*kaushal_ joined #nimrod
07:26:04*kaushal_ quit (Changing host)
07:26:04*kaushal_ joined #nimrod
07:26:15*kshlm is now known as Guest50252
07:26:16*kaushal_ is now known as kshlm
07:28:12*Guest50252 quit (Ping timeout: 245 seconds)
07:34:22*untitaker quit (Ping timeout: 245 seconds)
07:36:03Araquh oh, that's going to be a tough one
07:36:17AraqAporia uses threads ...
07:40:08*untitaker joined #nimrod
07:43:23Araqnah, should be simple
08:14:05*ehaliewicz quit (Ping timeout: 260 seconds)
09:07:56*Mat3 joined #nimrod
09:08:00Mat3hello
09:13:35*endou_ is now known as endou
09:35:31*bjz joined #nimrod
09:36:41*Mat3 quit (Ping timeout: 260 seconds)
09:45:48*edayo joined #nimrod
09:59:43*perturbation quit (Quit: Leaving)
10:22:13*Mat3 joined #nimrod
10:29:50*kuzy000_ joined #nimrod
10:55:00*Mat3 quit (Quit: Verlassend)
11:15:29*edayo_ joined #nimrod
11:18:19*edayo quit (Ping timeout: 244 seconds)
11:24:09*bjz quit (Ping timeout: 246 seconds)
11:24:42*bjz joined #nimrod
11:34:21*noam_ quit (Ping timeout: 260 seconds)
11:51:00*boydgreenfield joined #nimrod
12:00:52*EXetoC quit (Ping timeout: 240 seconds)
12:06:54*francisl joined #nimrod
12:10:55*francisl quit (Client Quit)
12:22:30*boydgreenfield quit (Quit: boydgreenfield)
12:42:57*johnsoft quit (Ping timeout: 260 seconds)
12:43:43*johnsoft joined #nimrod
13:16:48*francisl joined #nimrod
13:18:34*BitPuffin joined #nimrod
13:20:07*BitPuffin quit (Client Quit)
13:20:22*BitPuffin joined #nimrod
13:21:41*francisl quit (Ping timeout: 260 seconds)
13:31:40*francisl joined #nimrod
13:50:53*darkf quit (Quit: Leaving)
14:07:02*TieSoul is now known as azum4roll
14:07:38*azum4roll is now known as TieSoul
14:10:42*kshlm quit (Ping timeout: 245 seconds)
14:12:12*francisl quit (Quit: francisl)
14:12:33*vendethiel- joined #nimrod
14:12:54*vendethiel quit (Ping timeout: 258 seconds)
14:19:44*vendethiel joined #nimrod
14:21:49*vendethiel- quit (Ping timeout: 260 seconds)
14:27:07*francisl joined #nimrod
14:44:38*perturbation joined #nimrod
15:06:12*ronchilla__ joined #nimrod
15:09:12*kshlm joined #nimrod
15:09:29*edayo_ quit (Ping timeout: 260 seconds)
15:31:01*brson joined #nimrod
15:32:08*darkfusion quit (Quit: Lost terminal)
16:12:49*noam joined #nimrod
16:24:27*TieSoul quit (Ping timeout: 245 seconds)
16:34:20*betawaffle joined #nimrod
16:37:56*q66 joined #nimrod
16:38:16*EXetoC joined #nimrod
16:38:43*rektide_ is now known as rektide
16:44:29*boydgreenfield joined #nimrod
16:56:50*boydgreenfield quit (Quit: boydgreenfield)
17:00:03*francisl quit (Quit: francisl)
17:03:25*francisl joined #nimrod
17:12:05*TieSoul joined #nimrod
17:15:15*dapz joined #nimrod
17:18:42*francisl_ joined #nimrod
17:23:05*francisl_ quit (Ping timeout: 244 seconds)
17:28:13*kuzy000_ quit (Quit: No Ping reply in 180 seconds.)
17:29:27*kuzy000_ joined #nimrod
17:46:45*BitPuffin quit (Ping timeout: 260 seconds)
17:48:42*wkoch joined #nimrod
17:53:08*ehaliewicz joined #nimrod
17:59:55*BitPuffin joined #nimrod
18:06:18*BitPuffin quit (Ping timeout: 246 seconds)
18:10:25*Mat3 joined #nimrod
18:10:32Mat3hello
18:12:32*phobophilos quit ()
18:13:10*vezzy joined #nimrod
18:13:10*vezzy quit (Client Quit)
18:14:41*vezzy joined #nimrod
18:19:57reactormonkMat3, o/
18:22:17Mat3(-_-)
18:33:11*kshlm quit (Ping timeout: 258 seconds)
18:38:13*Matthias247 joined #nimrod
18:43:01Araqhi Mat3. what's up?
18:43:15Mat3hello Araq
18:44:44Mat3I've uploaded my sources to Github and sync it with my current work (modtly) daily
18:46:31*ehaliewicz quit (Remote host closed the connection)
18:47:10Mat3beside that I work on some bugfixes and tests as preparation for rewriting the code generator of these C compiler
18:48:16Araqnice
18:48:18*Mat3 wonders why every changed file of a git repro need to be newly added to the repro for uploading
18:48:42AraqMat3: no you can use 'git commit -am "message here" '
18:48:49Mat3ah thanks
18:50:40*dapz quit (Read error: Connection reset by peer)
18:51:51Mat3otherwise git seem to be now easier usable
18:52:40Mat3what licence do you prefer ?
18:56:57*edayo_ joined #nimrod
19:00:25*ronchilla__ quit (Ping timeout: 260 seconds)
19:11:51*vezzy quit ()
19:13:18*quasinoxen joined #nimrod
19:15:12*Sht0 joined #nimrod
19:23:41samlis nimrod now nim?
19:24:36samlwhat's wrong with nimrod?
19:26:14Mat3saml: please take a look at the forum
19:26:44*Jehan_ joined #nimrod
19:28:29Jehan_For the renaming: See http://forum.nimrod-lang.org/t/541/2 (second post from the top).
19:29:07Jehan_But the short answer is that a name that is slang for "idiot" in US English can pose problems.
19:31:53samlidiot is good. like Go is idiot
19:32:09samlanyways sounds good
19:36:34Mat3https://en.wikipedia.org/wiki/Nim
19:37:57*Jesin quit (Quit: Leaving)
19:39:37*francisl quit (Quit: francisl)
19:40:55*francisl joined #nimrod
19:42:54*dloss joined #nimrod
19:43:53*EXetoC quit (Ping timeout: 260 seconds)
19:47:07*dloss quit (Ping timeout: 246 seconds)
19:49:37*EXetoC joined #nimrod
19:50:11*flaviu1 joined #nimrod
19:50:44*Mat3 quit (Quit: Verlassend)
20:04:24*brson quit (Ping timeout: 272 seconds)
20:05:38*brson joined #nimrod
20:09:01*edayo_ quit (Ping timeout: 258 seconds)
20:10:10*dapz joined #nimrod
20:10:43*Shoop joined #nimrod
20:11:56ShoopBeginner here - How do you look at the c source code that nimrod compiles to?
20:14:50*dapz quit (Read error: Connection reset by peer)
20:17:17Jehan_Shoop: It's in the nimcache directory.
20:17:29ShoopOh nice
20:17:31Shoopthanks
20:18:19Jehan_Shoop: You can also use --embedsrc to embed the original Nimrod source code in the C output and --lineDir:on to generate #line directives in the C code.
20:18:30Jehan_Both can make it easier to see where the code comes from.
20:18:39Shoopthat sounds nice. ill try it out
20:23:23*Shoop quit (Quit: Page closed)
20:29:18*Ven joined #nimrod
20:45:52*Mat3 joined #nimrod
20:49:45Mat3is a licence which permits usage except for commercial purposes compatible to the MIT licence ?
20:52:19*bob_ joined #nimrod
20:55:07bob_is there an editor with good autocomplete? I can't get aporia to work and from the screenshots it doesn't seem to have function signatures
20:56:35bob_I am using nimlime now but I need to press ctrl+space for it to activate and it freezes the editor for 2 seconds, presumably because it is making a blocking call to the nimrod ide helper
20:57:25Araqbob_: do you use a release build of the compiler?
20:57:34Araqcause then it should be faster than 2 seconds
20:57:49AraqJehan_: your setjmp patch is overlfy complicated :P
20:57:52Araq*overly
20:58:00Jehan_Araq: Yes.
20:58:09Jehan_That's so it won't break building from csources.
20:58:28Araqhrm dunno that shouldn't be a problem
20:58:34Jehan_It is a problem.
20:58:47Araqjust make setjmp a .compilerproc and use that?
20:58:48Jehan_The compiler generates setjmp(), the library has _longjmp().
20:59:07Jehan_If you mix and match the two, you get crashes.
20:59:12bob_Araq: no i just downloaded 0.94 from the website
20:59:32Araqbob_: I sure hope that *is* a release version :-)
20:59:36Jehan_setjmp isn't the problem, longjmp is. But yeah, I could do that, I think. Will look at it.
20:59:49Araqspeaking of which
20:59:53Jehan_Though that means that I have to familiarize myself with how compiler procs work.
20:59:59bob_0.9.4 I mean which is the latest version on the website
21:00:01Araqshouldn't the GC use the same for speed?
21:00:02Jehan_Hmm, wait, that may still break building from csources.
21:00:17Araqstdlib gets a new .compilerproc
21:00:19Jehan_Since the csources compiler doesn't know the compiler proc.
21:00:21Araqcodegen uses that
21:00:31Araqold codegen doesn't use it
21:00:34Araq--> no problem?
21:01:02Jehan_Well, the old codegen can't handle the compiler proc?
21:01:21*def- quit (Ping timeout: 260 seconds)
21:02:00Jehan_About the GC: No idea how frequently the GC uses exceptions.
21:02:28Jehan_Oh, it uses setjmp() directly. Ugh ...
21:03:10Araqbob_: did you build from source?
21:03:11Jehan_Ah, to capture registers, I forgot that.
21:03:39bob_Araq: nimrod? no I downloaded the full x64 package
21:03:40Jehan_That's once per collection cycle, though, could be worse. Still, unnecessary overhead.
21:03:59bob_Nimrod Compiler Version 0.9.4 (2014-04-21) [Windows: amd64]
21:04:11Jehan_Okay, let me figure out how compiler procs work and I'll try to provide a better solution.
21:04:29AraqJehan_: well I could tell you but I guess that takes away the fun?
21:05:03Jehan_Araq: I have a basic idea, just not enough to actually hack the compiler where they are involved.
21:05:33Araqyou use #foo in some appropriate format string
21:05:41Araqand do
21:05:58Araqproc foo() {.compilerproc.} somewhere in system.nim
21:06:07Araqthat's it
21:06:09Jehan_Also, what about the procedures in system/ansi_c.nim? _setjmp()/_longjmp() and sigsetjmp()/siglongjmp() are POSIX, but not ANSI, so they should probably stay.
21:06:18Jehan_Huh. That's easier than I thought.
21:06:44Jehan_system.nim means also everything that system.nim includes, right?
21:06:50Araqright
21:06:52Araqin fact
21:07:00Araqyou can put .compilerproc in some other module
21:07:20Araqbut then the programmer would have to import that somewhere
21:07:44Jehan_Yeah, I got that.
21:07:45AraqRTTI uses that feature for reasons that I forgot
21:08:43Jehan_Okay, I'm still not sure that'll get me around the csources problem, but I'll give it a whirl.
21:08:45*kuzy000_ quit (Ping timeout: 260 seconds)
21:08:52Araq.compilerprocs are not the same as .magic
21:09:02Araq.magic causes compatibility issues
21:09:03Jehan_Yeah, seeing that now.
21:09:21Jehan_It's not a compatibility thing, it's about matching up setjmp() and longjmp() implementations.
21:09:34Jehan_If the compiler uses one and the stdlib another, things will break.
21:09:50Araqah ok
21:10:26Araqyeah well, I often do:
21:10:32Jehan_That's why I used a defineSymbol().
21:10:38AraqdefineSymbol("nimNewSetjmp")
21:10:50Araqand in then in excpt.nim you can test for that
21:11:02Araqbut yeah, you already do that I guess
21:11:26Jehan_That's pretty much what I was doing. I also allow to switch between setjmp() implementations, in case some oddball platform doesn't support one or the other.
21:12:39Jehan_I'm honestly more worried about the correctness issues with using setjmp() for exception handling.
21:12:52Jehan_But that's a fairly nasty problem.
21:13:12Araqthe C standard is broken I think
21:13:21Araqit requires you to add volatile
21:13:25Jehan_It's not that it's broken, it's to keep the implementation simple.
21:13:35Jehan_setjmp() simply dumps all registers.
21:13:42Araqbut what if the var comes from something that has been inlined?
21:14:03Jehan_Compiler doesn't inline functions that have setjmp(), AFAIK.
21:14:14Jehan_At least I haven't been able to force inlining of them.
21:14:28Araqthat 'volatile' is also used in other contexts and causes bad codegen doesn't help either
21:14:34Jehan_Yeah.
21:15:18Jehan_The C++ backend also cries when you make it take the addr() of a volatile variable.
21:15:18Jehan_Fortunately, it doesn't need setjmp().
21:15:18Araqso the compiler can't inline these? o.O
21:15:23Araqthat's pretty bad
21:15:32Jehan_Not so much "can't" as "has to be extremely careful".
21:15:44Jehan_But that's a reason why libunwind was written.
21:16:13Jehan_It provides an alternative setjmp()/longjmp() implementation that only changes stack and frame pointer.
21:16:29Araqwell I think the current solution is not bad
21:16:38Araqeverything in the 'try' gets the volatile
21:17:04Araqit didn't bite us in all these years
21:18:07Jehan_Because typically, most exception handlers throw away everything the try clause does.
21:18:22Jehan_It will bite you as soon as you try to actually rollback anything within it.
21:19:44Jehan_This is where having a garbage collector really helps in that it minimizes the need to do rollback.
21:19:46AraqI can't follow you
21:20:05Araq'var' outside a 'try' is not protected (declared as volatile)
21:20:13Araqbut vars within a 'try' are
21:20:33Araqthis seems like a nice compromise? we only need to document it well
21:20:35*francisl_ joined #nimrod
21:21:02Jehan_It's about vars *used* within a try, not the ones *defined* within the try.
21:21:48Araqyes I know
21:21:57Jehan_Well, assigned to.
21:22:09AraqI consider it a workable compromise
21:22:31Araqbut I see
21:22:36*Mat3 added a licence
21:22:38Araqwe can easily do better I guess
21:22:50Jehan_Hmm, interesting, I had no idea that there was already a mechanism for it.
21:22:56Jehan_I'm now seeing it within the compiler.
21:23:02AraqMat3: usually GPL prevents comercial usage
21:23:12Araqwell effectively it does
21:23:19Araqin theory it doesn't bla bla bla
21:23:34Jehan_GPL also prevents usage with anything that has an incompatible license.
21:24:03*Jehan_ is not a huge fan of the GPL for anything but standalone software.
21:24:27Mat3ok, I have choosen a MIT based licence which permits non commercial usage
21:24:44AraqMat3: what's its name?
21:24:53*francisl_ quit (Ping timeout: 240 seconds)
21:25:00Mat32 clauses MIT licence
21:25:11Araqlol
21:25:33Araqthat's misleading :D
21:25:33*Jesin joined #nimrod
21:26:01Mat3oh, sorry
21:27:50Mat3anyhow, I think it is compatible to GPL licences
21:28:02bob_what editor do you all use
21:28:06Jehan_Umm, there's just one MIT license?
21:28:27AraqNim is MIT, so it needs to be compatible with it
21:28:45Mat3bob_: Joe (Joe's Own Editor) + gedit
21:28:46*Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
21:28:58Araqyou can use LGPL with an explicit static linking exception
21:29:15Araqbob_: aporia
21:29:19Jehan_Probably just MIT for the sake of simplicity.
21:29:29Mat3I will take a look at it
21:29:52Jehan_As I recall, the LGPL with a static linking exception is a bit on the tricky side, legally.
21:30:03Mat3bob_: and ed
21:30:36Jehan_Araq: I'll give the setjmp() problem another shot, probably by tomorrow.
21:31:10AraqMat3: I think you can also pick anything else and give us special rights to use it however we want :D
21:32:18Mat3ehm ok
21:32:46Araqor you keep it GPL, we use it and you simply don't sue us? I dunno
21:34:12*BlaXpirit quit (Quit: Quit Konversation)
21:34:18AraqJehan_: sure, no rush
21:34:44flaviu1You don't really need the LGPL with a static linking exception
21:35:23Jehan_Araq: Can an importc procedure be a compilerproc?
21:36:04AraqJehan_: no
21:36:05flaviu1The goal of the static linking thing is to allow the user to replace/modify the library however they want. Object Code is explicitly mentioned a perfectly fine solution for that.
21:36:38Jehan_Araq: Then I can't use it for setjmp(), because setjmp() needs to be a macro or builtin C function.
21:36:39*francisl quit (Ping timeout: 246 seconds)
21:37:00Jehan_Can't create a new stackframe.
21:37:21flaviu1Jehan_: Oh, I wanted to show you http://jeffreykegler.github.io/Ocean-of-Awareness-blog/individual/2014/02/semantic_ws.html
21:37:21flaviu1I think that's pretty cool, even though Araq thinks it could be done with recursive descent
21:37:38Jehan_flaviu1: I saw it in the logs.
21:37:40*nande joined #nimrod
21:37:55Jehan_The problem is not that it's not cool – it is.
21:38:06AraqJehan_: you mean it can't be an .inline proc?
21:38:29Araqso setjmp cannot be wrapped by a function in C?
21:39:12Jehan_The problem is that a programming language grammar should not have any ambiguities in the first place that need to be resolved smartly. Because if it does, there may be a mismatch between what the parser thinks the code does and what a human thinks the code does.
21:39:17Jehan_Araq: Correct.
21:39:27Jehan_It needs to save the SP, among other things.
21:39:39Jehan_So the SP must not be manipulated by setjmp().
21:40:53Jehan_As a consequence, setjmp() is generally either an intrinsic, a macro, or a combination of both.
21:41:37Araqok. it's good to know that C is a simple language
21:42:47Araqsometimes I have my doubts about it
21:42:48Jehan_It's a portable machine language. :)
21:42:57Araqbut then I read some reddit comments
21:43:15Jehan_It's only simple compared to C++. :)
21:44:15Araqwell here is the lesson to take from it:
21:44:37Jehan_Oh, setjmp() itself can actually be implemented as a function that uses the return data to construct the necessary information. But then it still can't be called indirectly. :)
21:45:11Araqusing function calls to provide new forms of control flow is broken beyond repair
21:45:14Mat3Jehan_: It was once intended as portable assembler, now it is a standardisated language for unintended code obfuscation ;)
21:45:47Jehan_Mat3: It's still the closest thing to a portable assembler that we have. Well, one that's actually supported on all platforms that matter.
21:47:18Jehan_Araq: Never look at continuation-passing style then. :)
21:47:24Mat3yes, beside often low-level details relate on non portable libraries
21:47:49Mat3(or incompatible, compiler dependent extensions)
21:48:07Jehan_That's what the gods gave us #ifdef and autoconf for. :)
21:48:15Jehan_(I didn't say they were nice gods.)
21:48:31Araqeven worse they were no gods
21:48:38Araqbut fat guys with bad haircuts
21:49:17Jehan_But they had beards. :)
21:50:23Mat3lol
21:51:03NimBotAraq/Nimrod devel d0b292b Reimer Behrends [+0 ±1 -0]: Fix permissions for createDir() on Unix systems.... 3 more lines
21:51:03NimBotAraq/Nimrod devel 7d33706 Andreas Rumpf [+0 ±1 -0]: Merge pull request #1541 from rbehrends/mkdir-perms... 2 more lines
21:52:46AraqJehan_: so what do we do with your changes to make it compile as C++?
21:53:46Jehan_Araq: Umm, what do you mean?
21:54:24Jehan_The mkdir permission fix should not affect that at all, that just changed a couple constants?
21:54:43Araqhttps://github.com/rbehrends/Nimrod/commit/9a9cadf0a4839527264145c1419549cd225c687b
21:55:07Jehan_Oh.
21:55:25Jehan_That's an initial hack. More to get the ball rolling and to get feedback rather than final solution.
21:56:00Araqwell yes
21:56:05AraqI don't like it :P
21:56:11Araqso much for the feedback
21:56:13Jehan_Yeah. It does work, though.
21:56:16Araqbut seriously
21:56:29Araqwhy doesn't -fpermissive work for that?
21:57:01Jehan_Because -fpermissive isn't meant for circumventing const casts?
21:57:34Jehan_I dunno, you have to ask the people who write C++ compilers.
21:58:29Araqwell the compiler used to compile as c++
21:58:42*def- joined #nimrod
21:58:45Araqeither additions to posix.nim made it not compile
21:58:53Jehan_It's the CAAS stuff.
21:59:07Araqor g++ got stricter
21:59:38Araqwhat we really need is .compileAsCpp per *module*
21:59:40Jehan_Actually been using clang. Hmm, let me see if g++ is more permissive.
22:00:37Jehan_And wrap stuff as extern "C" in compile-as-c modules? Hmm, no idea if that works to circumvent const casts.
22:01:01Jehan_After all, it's gai_strerror() which creates the problem, which already should be a C function. I think.
22:02:21Jehan_Ah, g++ -fpermissive works, clang++ -fpermissive doesn't.
22:09:57Jehan_Hmm, if I use "nim cpp" AND "--cc:gcc" AND "--passc:whatever", the --passc gets ignored. Why?
22:10:22*brson quit (Ping timeout: 272 seconds)
22:11:26*willwillson joined #nimrod
22:11:41*brson joined #nimrod
22:13:05bob_why does it say Error: unhandled exception: The system cannot find the file specified. [EOS] when I try to use check on aporia? I set nimrodCmd = r"C:\Program Files (x86)\Nimrod\bin\nim.exe" and it still crashes
22:17:42Mat3ciao
22:17:46*Mat3 quit (Quit: Verlassend)
22:18:20AraqJehan_: --cc needs to reset things
22:18:34Jehan_Yeah, but --passc occurs after that.
22:18:55Araqthat might not matter
22:19:08Araqbut I guess you're right and it's a bug
22:20:18Araqextccomp.setCC sets compileOptions and linkOptions
22:22:19Araqbut "passc" in commands.nim is active for passCmd2, passPP
22:22:26Araqwhich seems correct. weird.
22:22:30Jehan_Okay, -fpermissive doesn't work on clang alone.
22:22:47Jehan_It works for both gcc itself and the gcc wrapper for clang.
22:25:16*bob_ quit (Quit: Page closed)
22:37:04*bogen joined #nimrod
22:42:59Jehan_Araq: What do you think of a forcecast pragma that forces the cast of the result of an importc function to the type the compiler thinks it is?
22:47:03AraqJehan_: yeah I've been thinking about something like this
22:48:21Araqbut that doesn't solve:
22:48:51Araqvoid takesConst(const int* i);
22:49:08Araqit's not just return types that need to be casted
22:49:44Jehan_You generally can pass non-const actual arguments to const formal arguments?
22:50:23Araqcan I?
22:51:04AraqI remember warnings about that
22:51:19Jehan_void takesConst(const char *s) {
22:51:19Jehan_ char *foo;
22:51:19Jehan_ takesConst(foo);
22:51:19Jehan_}
22:51:25Jehan_Compiles without warnings.
22:52:20Jehan_const can generally be added, just not removed. Same for volatile.
22:52:25Araqwhat about const char* const s ?
22:52:46Jehan_Also compiles.
22:52:58Jehan_I wasn't actually sure about that, but it does.
22:53:52Araqok, that means the compiler should emit 'const' like no tomorrow for C++ interop?
22:54:01Jehan_Huh?
22:54:11Araqa Nim parameter is always 'const'
22:54:36Jehan_Yeah, but you're making compilation slower.
22:55:00Araqbut not by much
22:55:07Jehan_And it might make the compiler barf on other things when you do stuff with a const ptr that you shouldn't do by some obscure appendix to the standard.
22:55:38Jehan_In any event, what breaks C++ compilation sometimes is the const return values that get assigned to a non-const variable.
22:55:44Araqyeah but this means that NIM_CONST can be 'const' for C++ and someProc(myConst) works
22:56:02Araqwe can make 'let' vars const
22:56:25Jehan_Would have to look at that more closely.
22:56:51Araqand then we don't need .forcecast except in very rare cases
22:57:50Jehan_Yeah, the problem is that "const T *s" doesn't allow assignment to s[i].
22:58:04Jehan_Which at least for var parameters would be an issue.
22:58:17Araqwell 'var' cannot be c++'s const
22:58:29Jehan_Oh, you're only talking about non-var parameters?
23:00:00Jehan_I'm still not entirely sure what the benefit would be.
23:00:19Araqwell it would be "const" correct
23:00:35Araqcan be useful for when you tell Nim to generate a header
23:00:39Jehan_Hmm.
23:01:08Jehan_It might be worth testing it, depending on how much effort it is.
23:01:38Jehan_Oh, there IS a possible issue.
23:02:07Jehan_Nim non-var parameters may always be const, but that's not true for importc functions.
23:02:50Araqthat's not an issue
23:02:54Araqhow can it be?
23:03:08Araqimportc, header means the header is not generated
23:03:15Jehan_When you pass a Nim non-var parameter to an external C function.
23:03:21Araqimportc, dynlib means it's binary compatible anyway
23:03:24Jehan_The prototype is still in the #include.
23:04:04Araqyes but so what? we pass const things to ... oh I see
23:04:52Jehan_It's the gai_strerror() problem in reverse.
23:05:53Jehan_I still think a forcecast pragma might be a good idea regardless (though I don't like the name, just the idea).
23:08:48AraqI'd like to conflate it with .importcpp but don't know how
23:09:59Jehan_Hmm, what do you mean?
23:10:32Jehan_One other option I've thought about is to have a pragma that allows you to provide the actual C/C++ type signature.
23:10:51Araqproc gai_strerror(): cstring {.importcpp.}
23:10:53Araqinstead of
23:11:02Araqproc gai_strerror(): cstring {.importc, forcecast.}
23:11:08Jehan_E.g. {.importc, signature["void", "const char *"].}
23:11:29Araqhow does that help?
23:11:57Jehan_proc gai_strerror(): cstring {.importc, signature: ["const char *"].}
23:12:20Jehan_Hmm, wait, it doesn't help with the result.
23:12:26Jehan_Because you'd still have to parse the C type.
23:13:20Jehan_By the way, why {.importcpp.}?
23:13:32*perturbation quit (Quit: Leaving)
23:13:38Jehan_It's a C function either way, it's just that the C++ compiler is more pedantic about C semantics.
23:14:17Araqyes I know
23:14:18Jehan_The C compiler still screams warnings, but it's C, and assumes that you know what you're doing.
23:18:36*francisl joined #nimrod
23:19:40Araqwell for now .forcecast seems like the best solution
23:20:12Jehan_I don't have a better idea, either. :)
23:20:42Jehan_Not a feasible one, at least. :)
23:20:59Araq.fuzzyReturntype might be a better name though
23:23:36Jehan_I was thinking forcecast because at some point it may be necessary to deal with importc vars, too.
23:24:02Jehan_Generally, APIs that want you to assign to/from external vars are rare (and ugly), but they exist.
23:25:05*darkf joined #nimrod
23:25:06Araq.handwave ?
23:25:41Araq.dismiss?
23:26:15Jehan_Well, I still don't have a better name than forcecast.
23:26:17*quasinoxen quit (Quit: No Ping reply in 180 seconds.)
23:26:27*Matthias247 quit (Read error: Connection reset by peer)
23:26:54Jehan_It still has the virtue of being pretty clear about what it's about.
23:27:02*quasinoxen joined #nimrod
23:27:37Araq.dismissConst?
23:28:09AraqI think it's not that clear because it doesn't contain const
23:28:19Jehan_stripconst?
23:28:34Jehan_On the other hand, it can also be used for volatile.
23:28:38Araqhrm
23:29:05Araqstripmodifier?
23:30:04Jehan_Hmm, const_cast?
23:30:21Jehan_That's after all exactly what the C++ version does.
23:30:39Jehan_const_cast can remove both const and volatile.
23:30:44Araqdunno
23:33:03AraqI think I prefer constRet
23:33:09Araqor constReturntype
23:33:25Jehan_The other thing is that it can also be used to cast, say, a void * to a char *.
23:33:40Araqit should be declarative
23:33:53Araqwe need additional information to generate proper c++ code
23:34:02Araqand so it should be declarative
23:34:21Araqand then the compiler can generate whatever conversion that is required
23:34:41Jehan_Yeah, that's why I was thinking about a signature pragma.
23:34:58Jehan_But that would require parsing of C types. :)
23:35:00Araq.stripconst assumes that the programmer knows about the codegen issues
23:35:12Jehan_Yeah.
23:35:50Jehan_What you really want to express is that the function's type cannot be fully expressed in Nim.
23:37:23Jehan_{.retype.}?
23:37:54Jehan_{.brokentype.}?
23:38:09*darkf quit (Read error: Connection reset by peer)
23:38:32*darkf joined #nimrod
23:41:05Jehan_Meanwhile, I'll drop the PR.
23:41:13Araqnah
23:41:30Araqit's a nice idea too
23:42:02Araqyou declare the type as const[cstring] and let the compiler insert a cast
23:42:27Jehan_Yeah, but that's a bigger change.
23:42:49Araqwell it doesn't require yet another pragam
23:42:53Araq*pragma
23:43:06Jehan_const is a keyword.
23:43:12Jehan_Well, you could define cconst.
23:43:33Araqthe global converter is not necessary, but convenient
23:43:57Araqbut for gai_error we can also easily write it explicitly
23:44:03Jehan_My problem with that was that I didn't want to pollute the namespace, since you'll never call it explicitly.
23:44:11Jehan_Anonymous converters might be nice.
23:44:43Araqno way
23:44:53Araqimport foo except someConverter
23:45:00Araqneeds to be possible
23:45:14Araqconverters are evil ;-)
23:45:37Jehan_Heh. :)
23:45:53Jehan_They can sometimes be a necessary evil, though.
23:46:01Varriount_Araq: Sorry I'm not around more often. My classes are really soaking up my time.
23:46:15AraqVarriount_: excuses
23:46:55*Varriount_ is now known as Varriount
23:48:26AraqJehan_: thinking about it
23:48:31Araqwhat about:
23:49:32Araqproc gai_error() {.importc: "((char*) gai_error($#))".}
23:49:59Jehan_Hmm.
23:50:19Jehan_$# is the placeholder for the arguments, I take it?
23:50:26Araqyup
23:50:34Jehan_That's actually pretty neat.
23:51:25Jehan_Curious, though, why $# instead of the more common $* or $@?
23:52:01Araq% supports $#, but you're right
23:52:24Jehan_Maybe my mind is too warped by bash and friends. :)
23:52:42Araqwell there is a subex standard for these things
23:53:30Jehan_Subex?
23:54:19Araqhttp://nimrod-lang.org/subexes.html
23:54:35Araqwell it's my "standard"
23:54:42Araqas I invented them
23:55:56Jehan_Oh, I see.
23:56:23Araqbut yeah
23:56:34Araq$* should be an alias for ${..}
23:57:29Araqhrm these are actually really cool. too bad nobody uses them :-)
23:57:43Jehan_Hmm, nifty. Another module I didn't know and which is useful.