00:00:44 | Araq | for objective C and c++ support, yeah |
00:00:56 | Jehan_ | Even in C sometimes. |
00:01:10 | Araq | for what? |
00:01:43 | Jehan_ | Because importc can't handle everything? |
00:02:19 | Araq | well a concrete example would be nice |
00:02:23 | Jehan_ | Well, technically, I guess that you can set up a special .h file that just creates a define. |
00:02:28 | NimBot | nimrod-code/csources master 33b66f7 Araq [+69 ±2492 -0]: csources generated for version 0.9.6 |
00:02:36 | Jehan_ | My example would be that you can't use importc for operators. |
00:03:20 | Araq | the best example is #omp parallel for stuff |
00:03:59 | Araq | I had to add a builtin || iterator to get it |
00:07:00 | NimBot | Araq/Nimrod devel 134311c Araq [+0 ±1 -0]: '.emit' pragma produces a trailing newline |
00:25:33 | * | Matthias247 quit (Read error: Connection reset by peer) |
00:29:26 | * | Jesin quit (Quit: Leaving) |
00:32:19 | * | Jesin joined #nimrod |
00:43:21 | * | Etheco quit (Quit: Leaving) |
01:02:32 | Varriount | Araq: Hm. What kind of error should mismatched visibility markers raise? I can't just say "Visibility markers don't match", because visibility doesn't have to match... |
01:05:10 | Varriount | Araq: Currently I have "match to non-public forward declaration at \'$1\' can't be public: \'$2\'" |
01:07:55 | fowl | o_o |
01:07:56 | NimBot | Araq/Nimrod devel 434dcd7 Milos Negovanovic [+0 ±1 -0]: Preserve nil <-> NULL between Nimrod and database. |
01:07:56 | NimBot | Araq/Nimrod devel 8b4d4be Milos Negovanovic [+2 ±33 -2]: Merge branch 'devel' of github.com:Araq/Nimrod into devel... 2 more lines |
01:07:56 | NimBot | Araq/Nimrod devel 1528421 Milos Negovanovic [+0 ±1 -0]: Merge branch 'devel' of github.com:Araq/Nimrod into devel... 2 more lines |
01:07:56 | NimBot | Araq/Nimrod devel b22f858 Milos Negovanovic [+0 ±1 -0]: Merge branch 'devel' of github.com:Araq/Nimrod into devel... 2 more lines |
01:07:56 | NimBot | 5 more commits. |
01:12:43 | * | dapz quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
01:25:12 | will | Varriount: How about something like: Visibility marker at definition doesn't match forward-declaration |
01:25:54 | Jehan_ | will: The thing is that that's misleading. |
01:26:09 | will | ok, I'll shut up :D |
01:26:16 | Jehan_ | You can have a proc foo*() forward declaration and then a proc foo() = … implementation later. |
01:26:29 | will | I see |
01:37:46 | * | boydgreenfield quit (Quit: boydgreenfield) |
01:41:22 | * | dapz joined #nimrod |
01:42:16 | * | boydgreenfield joined #nimrod |
01:46:57 | * | dapz quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
01:47:54 | * | dapz joined #nimrod |
01:48:44 | * | xenagi joined #nimrod |
01:58:35 | * | boydgreenfield quit (Quit: boydgreenfield) |
02:01:07 | * | superfunc quit (Quit: Connection closed for inactivity) |
02:08:43 | flaviu | "public implementation $1 has non-public forward declaration $2' |
02:10:07 | Triplefox | more money more problems |
02:10:11 | * | saml_ joined #nimrod |
02:10:57 | flaviu | I don't really mind what the error is, but "Visibility markers" is confusing, don't use that phrase |
02:24:47 | * | Jehan_ quit (Quit: Leaving) |
02:44:02 | * | will quit (Ping timeout: 256 seconds) |
02:50:09 | * | dapz quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
03:03:01 | * | Boscop__ joined #nimrod |
03:04:58 | * | boydgreenfield joined #nimrod |
03:06:29 | * | Boscop_ quit (Ping timeout: 255 seconds) |
03:28:21 | * | flaviu quit (Read error: No route to host) |
03:32:25 | Varriount | fowl: Thanks, I'll go with that. |
04:05:14 | * | dapz joined #nimrod |
04:18:48 | * | dapz quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
04:19:14 | * | boydgreenfield quit (Quit: boydgreenfield) |
04:28:34 | * | boydgreenfield joined #nimrod |
04:40:33 | * | xenagi quit (Quit: Leaving) |
04:45:04 | * | boydgreenfield quit (Quit: boydgreenfield) |
04:50:10 | * | dapz joined #nimrod |
04:50:13 | * | dapz quit (Client Quit) |
05:38:38 | * | boydgreenfield joined #nimrod |
05:48:02 | * | saml_ quit (Quit: Leaving) |
06:05:12 | * | Boscop__ quit (Read error: Connection reset by peer) |
06:05:30 | * | Demos quit (Read error: Connection reset by peer) |
06:16:16 | * | boydgreenfield quit (Quit: boydgreenfield) |
06:24:41 | * | nande quit (Read error: Connection reset by peer) |
06:30:00 | * | nande joined #nimrod |
07:28:50 | * | irrequietus joined #nimrod |
07:37:41 | * | gokr quit (Quit: Leaving.) |
07:44:44 | * | gokr_ joined #nimrod |
08:00:14 | * | gokr joined #nimrod |
08:06:25 | * | Francisco joined #nimrod |
08:08:22 | * | Fr4n quit (Ping timeout: 255 seconds) |
08:09:29 | * | irrequietus quit () |
08:54:14 | * | gokr quit (Quit: Leaving.) |
08:56:51 | * | Matthias247 joined #nimrod |
09:14:32 | * | rpag joined #nimrod |
09:15:06 | * | nande quit (Read error: Connection reset by peer) |
09:35:08 | * | Trustable joined #nimrod |
09:38:15 | * | noam_ joined #nimrod |
09:38:50 | * | xcombelle joined #nimrod |
09:41:37 | * | noam quit (Ping timeout: 258 seconds) |
10:33:41 | NimBot | nimrod-code/packages master c8f2ede Hitesh Jasani [+0 ±1 -0]: Add eternity package |
10:33:41 | NimBot | nimrod-code/packages master 1da4bf9 Andreas Rumpf [+0 ±1 -0]: Merge pull request #91 from hiteshjasani/master... 2 more lines |
10:47:49 | * | flaviu joined #nimrod |
11:06:53 | * | flaviu quit (Remote host closed the connection) |
11:11:16 | * | flaviu joined #nimrod |
11:17:44 | * | tdc joined #nimrod |
11:41:21 | * | tdc quit (Ping timeout: 260 seconds) |
12:18:47 | * | gokr_ quit (Ping timeout: 258 seconds) |
12:39:10 | * | gokr_ joined #nimrod |
12:46:00 | * | gokr_ quit (Ping timeout: 258 seconds) |
12:47:02 | * | ARCADIVS joined #nimrod |
13:03:38 | * | xcombelle quit (Ping timeout: 272 seconds) |
13:10:16 | * | gokr joined #nimrod |
13:27:22 | * | BitPuffin joined #nimrod |
13:28:04 | * | BitPuffin quit (Remote host closed the connection) |
13:29:19 | * | BitPuffin joined #nimrod |
13:33:04 | gokr | http://goran.krampe.se/2014/10/25/nim-socketserver/ |
13:35:51 | * | kshlm joined #nimrod |
13:37:32 | * | gokr quit (Ping timeout: 250 seconds) |
13:39:30 | * | kshlm quit (Read error: Connection reset by peer) |
13:51:02 | * | darkf quit (Quit: Leaving) |
13:55:02 | * | gokr_ joined #nimrod |
14:22:39 | * | xenagi joined #nimrod |
14:24:02 | * | BlaXpirit joined #nimrod |
14:34:47 | * | gokr joined #nimrod |
14:39:53 | flaviu | gokr: `TaintedString""` != `TaintedString("")` |
14:40:00 | flaviu | the first is also a raw string |
14:40:16 | flaviu | so it's more equivalent to `TaintedString(r"")` |
14:40:25 | * | xcombelle joined #nimrod |
14:40:54 | * | tdc joined #nimrod |
14:42:04 | * | tdc quit (Read error: Connection reset by peer) |
14:46:39 | * | vendethiel joined #nimrod |
14:47:51 | * | Matthias247 quit (Read error: Connection reset by peer) |
14:48:36 | * | will joined #nimrod |
14:51:09 | Araq | gokr: IO completion ports on Windows are implemented and work |
14:57:20 | gokr | Oh, cool :) |
14:57:33 | gokr | My bad, I will fix. |
14:59:00 | Araq | also ... we can fix tainted mode for the new async stuff, you know |
14:59:41 | Araq | will you update your article once it's fixed? |
15:01:32 | gokr | yeah, I am updating now |
15:01:39 | gokr | Oh, you mean.. .yes. |
15:02:32 | gokr | sure, i will. |
15:02:47 | gokr | I don't understand flaviu though. |
15:03:00 | gokr | Perhaps this is in the manual somewhere. |
15:03:14 | flaviu | gokr: r"" is a raw string, escape sequences don't work |
15:03:29 | Araq | his point is that TaintedString"" is not 100% equivalent to TaintedString(""), but to TaintedString(r"") |
15:03:51 | flaviu | "raw strings" is the name of the `r""` thing |
15:04:00 | gokr | Ah... http://nim-lang.org/manual.html#generalized-raw-string-literals |
15:04:18 | gokr | Ok, got it. But TaintedString() is still a conversion right? |
15:04:26 | Araq | sure |
15:04:27 | gokr | So its something built into the language? |
15:04:41 | gokr | These conversions I mean. |
15:05:12 | Araq | yes, but they work the same for every 'distinct' type |
15:05:34 | Araq | the compiler knows nothing about TaintedString |
15:05:35 | gokr | Right, for a distinct type its mainly a conversion in the "type" sense, right. |
15:06:08 | gokr | I just got confused first trying to find some kind of proc called "TaintedString" etc. |
15:06:15 | gokr | :) |
15:08:34 | * | johnsoft quit (Ping timeout: 245 seconds) |
15:08:55 | * | johnsoft joined #nimrod |
15:10:23 | * | will quit (Ping timeout: 240 seconds) |
15:10:26 | Araq | btw why do you compile with taintMode:on? |
15:11:09 | gokr | I just tried to do it - wouldn't that be the "correct" way - given that the program did something more interesting? |
15:11:59 | Araq | I don't know, it never found a bug in our code |
15:12:23 | gokr | The problem was in "net". I didn't investigate, but it failed compilation. |
15:12:34 | gokr | Further I think...cpp failed too. |
15:13:26 | Araq | but yeah, one should use it for servers |
15:13:29 | gokr | Sorry for a 10 liner: |
15:13:33 | gokr | lib/pure/net.nim(743, 18) Info: instantiation from here |
15:13:33 | gokr | lib/pure/net.nim(721, 10) Error: type mismatch: got (TaintedString, string) |
15:13:33 | gokr | but expected one of: |
15:13:33 | gokr | system.add(x: var seq[T], y: openarray[T]) |
15:13:33 | gokr | system.add(x: var string, y: char) |
15:13:33 | gokr | system.add(x: var string, y: string) |
15:13:34 | gokr | system.add(x: var seq[T], y: T) |
15:13:34 | gokr | system.add(x: var string, y: cstring) |
15:13:49 | gokr | That's with taintMode:on |
15:14:01 | gokr | Ok, gotta go and put together a makeup table for my daughter :) |
15:14:19 | gokr | I will update the article with the TaintedString and.. the IO Completion ports in 1 sec. |
15:14:19 | Araq | ok |
15:14:27 | Araq | ty |
15:15:29 | Araq | Varriount: can you guarantee the 64 bit installer downloads our 64 bit mingw? |
15:23:47 | Araq | bbl |
15:42:07 | * | gokr_ quit (Remote host closed the connection) |
15:42:21 | * | gokr_ joined #nimrod |
15:44:37 | * | Ven joined #nimrod |
15:49:32 | * | gokr_ quit (Remote host closed the connection) |
15:49:46 | * | gokr_ joined #nimrod |
15:52:00 | * | gokr_ quit (Remote host closed the connection) |
15:52:16 | * | gokr_ joined #nimrod |
15:56:38 | * | Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
15:57:05 | * | tdc joined #nimrod |
16:09:31 | * | gokr_ quit (Remote host closed the connection) |
16:09:46 | * | gokr_ joined #nimrod |
16:19:32 | * | gokr_ quit (Remote host closed the connection) |
16:20:29 | * | gokr_ joined #nimrod |
16:29:46 | * | Ven joined #nimrod |
16:41:49 | * | vendethiel quit (Quit: q+) |
16:44:02 | * | kemet joined #nimrod |
16:44:37 | * | will joined #nimrod |
16:48:11 | wan | btw gokr, you forgot the ":" after Content-Length |
16:49:57 | gokr | Ah! |
16:50:31 | gokr | Ok, I will fix that too. |
16:51:05 | gokr | I think at least ab got much happier when it got a reasonable HTTP response back ;) |
16:51:30 | * | xenagi quit (Read error: Connection reset by peer) |
16:51:49 | * | gokr_ quit (Ping timeout: 244 seconds) |
16:51:53 | * | gokr1 joined #nimrod |
16:52:03 | * | gokr_ joined #nimrod |
16:55:15 | Varriount | Darn! |
16:55:39 | * | gokr quit (Ping timeout: 244 seconds) |
16:55:45 | Varriount | Araq: It's my fault. The installer is downloading the wrong compiler. |
16:56:43 | Araq | Varriount: fix it asap |
17:01:51 | * | kemet quit (Remote host closed the connection) |
17:10:46 | * | gokr1 quit (Read error: Connection reset by peer) |
17:12:48 | * | gokr joined #nimrod |
17:19:38 | wan | gokr: in your spawnserver example, "Eternal loop where we use the old select API" but we don't, under the hood it's epoll. It just looks like the old select. |
17:26:03 | * | xcombelle quit (Ping timeout: 265 seconds) |
17:27:12 | * | untitaker quit (Ping timeout: 250 seconds) |
17:33:05 | * | untitaker joined #nimrod |
17:38:18 | NimBot | Araq/Nimrod devel d5b9439 Varriount [+0 ±1 -0]: Update nsis.tmpl... 2 more lines |
17:38:23 | * | gokr quit (Ping timeout: 240 seconds) |
17:38:40 | Araq | Varriount: nsis.tmpl is not the problem |
17:39:00 | Araq | it's --var:mingw=mingw32 vs --var:mingw=mingw64 |
17:39:56 | Varriount | Araq: Yeah, I got that. I just wanted to fix that as well. |
17:40:24 | Araq | *fix that*? what do you mean? |
17:40:48 | Varriount | The nimrod compiler needs gcc.exe in the path to work? |
17:41:27 | * | gokr joined #nimrod |
17:42:03 | * | Matthias247 joined #nimrod |
17:44:29 | Araq | nah |
17:44:40 | Araq | if you set some config option, it doesn't |
17:44:48 | Araq | well that used to be the case at least |
17:44:59 | Araq | no idea how newer mingws work |
17:45:44 | Varriount | Araq: Yes, however if you set the config option, the Nim compiler won't look for Mingw in the path variable (iirc) |
17:46:52 | Varriount | Since the same Nim binary is used for both installations with and without mingw, a method that works for both must be used. |
17:47:41 | Varriount | Sadly, that's the price of the configuration that nsis.tmpl has. |
17:48:10 | Varriount | https://drive.google.com/file/d/0B077nrrf63xtclIydjQ2QzhMMjg/view?usp=sharing |
17:48:28 | Varriount | ^ New installer, which I tested this time. |
17:49:36 | gokr | wan: That's an old comment - because I *did* use the old select before. But ... didn't I fix that? |
17:50:02 | gokr | Argh, missed that fix. Ok, will fix |
17:51:15 | gokr | wan: Fixed. :) |
17:51:32 | gokr | The article talks about this new selectors stuff, so... it was just an old remnant. |
17:56:30 | Varriount | Araq: ^ new installer link above |
18:00:33 | Araq | Varriount: alright thanks |
18:01:06 | Araq | this web based installer was a really good idea. 3MB downloads instead of gigabytes |
18:02:16 | * | tdc_ joined #nimrod |
18:05:53 | * | tdc quit (Ping timeout: 260 seconds) |
18:06:32 | * | xcombelle joined #nimrod |
18:11:40 | gokr | My next article will be "Nim and OO" so ... any interesting URLs or thoughts on that subject - shoot. |
18:14:31 | reactormonk | gokr, imo you can transcend OO to a bit more functional approach in nirmod with the dual syntax, but that's just my cents |
18:15:20 | Araq | gokr: ask fowl how his component system works ;-) |
18:15:49 | gokr | "dual syntax"? |
18:16:24 | gokr | You mean the UFCS? |
18:17:01 | gokr | Araq: Yeah, that sounded pretty advanced - gotta check those logs more carefully. |
18:17:20 | Araq | strictly speaking it's called "method invocation syntax" |
18:17:45 | Araq | because Nim had it before D and there is nothing "uniform" about a.f(b) |
18:18:05 | Araq | in fact I'd argue f(a, b) is the "uniform" syntax |
18:18:11 | gokr | Personally I feel Nimrod may benefit from a bit of ... thoughts or guidance - since I personally feel there is a great deal of flexibility here. |
18:18:31 | gokr | Not sure where I saw that acronym first. |
18:18:46 | gokr | I hadn't seen it until a few days back. |
18:18:54 | gokr | Someone writing about Nimrod I think. |
18:20:39 | gokr | I suspect (feel free to correct me) that in Nimrod you may start out with objects and procs for them, then perhaps add object variants - then gradually move to inheritance and eventually methods, when procs and overloading (and typeclasses - but those are pretty new, right?) doesn't cut it anymore. |
18:21:26 | Araq | yeah, perhaps. the "doesn't cut it anymore" never happens though :P |
18:21:42 | gokr | For a lot of code - you are probably right. |
18:22:49 | gokr | But it depends on the design - I guess I would start earlier with "object style" given my "Smalltalkish mind" - and someone from a more imperative tradition would instead juggle data with procs. |
18:23:21 | gokr | A big Perl system I worked with once SCREAMED for OO, but instead they just operated imperatively on very complicated nested hashes. |
18:24:09 | gokr | Btw, are the typeclasses thingy "ready to go"? In a beta sense? |
18:24:15 | gokr | Would love to play with that. |
18:25:50 | * | nande joined #nimrod |
18:26:06 | Araq | type classes are pre-beta, I think, but I didn't implement them nor did anything with them. |
18:26:49 | Araq | gokr: you think it screamed for OO, I would likely have thought "this screams for static typing" |
18:31:28 | Trustable | Araq, how should we fix terminate()? https://github.com/Araq/Nimrod/issues/1558 |
18:33:24 | gokr | Araq: Sure, but the fact that you have multi level nested hashes and sending them around and constantly messing with them in various ways - that *does* scream objects. |
18:34:39 | gokr | If you like to call them types and have procs operating on them using typed overloading - fine. IMHO that's basically OO. |
18:35:11 | gokr | (and of course decompose them into parts) |
18:36:29 | gokr | Which is btw how I am structuring the article - I hope to catch the Nim spirit in "keep it simple" as far as you can. |
18:37:12 | gokr | Araq: Ok if I bounce it on you before publishing it? It will not be ready until in a few days though |
18:38:27 | Araq | yeah sure |
18:40:38 | Varriount | gokr: I agree. I'm currently restructuring a price estimation tool (written in python) that esentially uses a giant dict to store data. There are several functions that operate on the data in this dict. |
18:41:02 | gokr | I am on watch for our system in Brazil. Always scary to see the "users on" pass 200 :) |
18:41:39 | Varriount | After the initial release of the tool to the people that requested it, I looked at what I had initially written and thought, "isn't this just recreating python classes?" |
18:43:04 | gokr | In Smalltalk (for some... reason I am not sure about) I seldom encounter that kind of code. |
18:44:45 | Varriount | gokr: I blame the CS class that I am taking this semester. |
18:45:44 | Varriount | I've was so sick and tired of Java and its restrictive OO structure, that when I initially wrote the code for that tool, I wanted to do something as far from OO as possible. |
18:50:39 | Araq | Trustable: dunno, just fix it |
18:51:30 | Trustable | Araq: Do you like the idea from cowboy-coders to give the process some milli seconds to shutdown? |
18:52:36 | Araq | Trustable: sure why not. this posix stuff never works anyway. |
18:52:56 | * | nande quit (Remote host closed the connection) |
18:53:28 | * | BlaXpirit quit (Quit: Quit Konversation) |
18:54:23 | Varriount | Araq: But Posix is an open standard! Surely it's perfect in every way! /s :P |
18:56:27 | Trustable | Araq, Varriount: What do you think of my suggested fix? https://github.com/Araq/Nimrod/issues/1558#issuecomment-60493461 |
18:57:53 | * | gokr1 joined #nimrod |
18:59:45 | * | gokr_ quit (Ping timeout: 258 seconds) |
19:00:21 | Araq | Trustable: tested the heck out of it? works on macosx, linux, solaris, surrealUnix? |
19:00:33 | Trustable | so far tested on linux |
19:00:49 | Araq | on linux without libc? |
19:01:14 | Araq | tested on a machine that only has flash memory and no cpu? |
19:01:15 | Varriount | What about Windows? Does this bug even apply? |
19:01:28 | * | gokr quit (Ping timeout: 272 seconds) |
19:01:41 | Trustable | No, for Windows a different code is used |
19:02:15 | Trustable | In general the question is: Should terminate() only kill the process itself, or also it's sub-processes. |
19:02:44 | Varriount | That should be up to the user (user being the programmer using the API) |
19:02:54 | Araq | yeah, what Varriount says |
19:03:05 | Trustable | sounds good |
19:03:21 | Varriount | In general, killing the process and all it's subprocesses is what is usually desired, however this isn't *always* true. |
19:03:40 | Trustable | Solve this with an additional parameter or a new proc? |
19:04:05 | Varriount | Hm. Tricky... |
19:04:44 | * | BlaXpirit joined #nimrod |
19:04:48 | Varriount | Trustable: What parameters does terminate take currently? |
19:05:01 | Trustable | Currently: proc terminate(p: PProcess) |
19:05:18 | Trustable | Suggestion: proc terminate(p: PProcess, terminateSubProcesses = true, milliSecsToWait = 100) |
19:06:18 | Varriount | I think adding on parameters is better, in this instance. |
19:06:22 | Trustable | ok |
19:06:33 | Varriount | Araq: Feel free to contradict me. |
19:07:00 | Trustable | The main issue: -p.id is not in any cases valid. So we have to use getpgid() I think. |
19:07:26 | Varriount | Trustable: Working with processes is never fun. It |
19:07:41 | Trustable | I have no experience. |
19:07:51 | Varriount | It has all the complications of threading, except that in this case, none of the threads are under your complete control. |
19:08:25 | Trustable | I have only one test case, and this is Aporia. |
19:09:08 | Trustable | Currently, Aporia kills the wrong process. |
19:16:18 | gokr1 | Trustable: Ha! That "Terminate process" thing? And kills Aporia :) |
19:16:26 | gokr1 | I have done it like 4-5 times, never learn. |
19:16:53 | Varriount | I don't use Aporia... I have Sublime Text & the command prompt. |
19:18:18 | gokr1 | I guess the Sublime addon is one of those mostly evolved? |
19:18:23 | gokr1 | It looked like it. |
19:20:04 | Varriount | gokr1: Well, it suits my needs. |
19:20:28 | Varriount | gokr1: There's probably more that could be done, but I've yet to hear any suggestions for additions. |
19:26:45 | * | tdc_ quit (Quit: Leaving) |
19:31:34 | * | johnsoft quit (Ping timeout: 256 seconds) |
19:32:14 | * | johnsoft joined #nimrod |
19:38:41 | Araq | Trustable: do you have write access for Aporia? |
19:41:51 | Trustable | Araq: No, I don't have write access. |
19:41:53 | Araq | Varriount: well Lua doesn't have that problem. Here hash tables and objects are the same. ;-) |
19:42:38 | Araq | Trustable: I'll ask dom96 to give you that. |
19:43:02 | Trustable | Good idea, there are some PRs waiting. |
19:45:51 | * | ehaliewicz joined #nimrod |
20:01:43 | NimBot | Araq/Nimrod bigbreak 134311c Araq [+0 ±1 -0]: '.emit' pragma produces a trailing newline |
20:01:43 | NimBot | Araq/Nimrod bigbreak 2dba3ac Araq [+0 ±1 -0]: Merge branch 'devel' into bigbreak |
20:01:43 | NimBot | Araq/Nimrod bigbreak a639824 Araq [+0 ±14 -0]: introduced 'benign' pragma |
20:03:53 | * | BlaXpirit quit (Remote host closed the connection) |
20:05:26 | * | BlaXpirit joined #nimrod |
20:19:49 | * | Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
20:47:07 | Varriount | Araq: What issues do you think I can work on? |
20:57:59 | Araq | Varriount: fixed that koch version issue? |
20:58:30 | Araq | and yes, I'm aware my .benign on bigbreak doesn't work yet |
20:58:45 | Varriount | Araq: What does .benign do? |
20:59:06 | Araq | it's simply an alias for gcsafe, locks: 0 |
20:59:11 | * | vendethiel joined #nimrod |
20:59:34 | Araq | locks: 0 means the proc doesn't use locking |
21:00:34 | Varriount | If memory can't be shared by threads, what are locks for? |
21:01:10 | Araq | it can be shared, what about allocShared? |
21:01:34 | Varriount | Oh, yeah. Globals are shared too, right? |
21:02:47 | * | Francisco quit (Ping timeout: 245 seconds) |
21:02:48 | flaviu | gokr1: I wish I had read your blog post before wrapping this library |
21:03:04 | flaviu | It would have made things much easier :) |
21:03:07 | gokr1 | Why didn't you? :) |
21:03:21 | Araq | Varriount: yep. |
21:03:32 | flaviu | I didn't check google, since I've wrapped stuff before |
21:04:07 | gokr1 | Yeah |
21:09:52 | * | Francisco joined #nimrod |
21:10:15 | Trustable | For what does benign stand? |
21:10:50 | rpag | in english? sometimes used like 'harmless' |
21:11:11 | Trustable | ah ok |
21:12:34 | Varriount | Trustable: I find it's used mostly in medical contexts - 'they found a large but benign tumor on her kidney' |
21:12:54 | gokr1 | Or "benign dictator" |
21:12:59 | fowl | rpag, sup |
21:13:55 | flaviu | oh well, @@ works nearly as well :P |
21:14:11 | rpag | y0 fowl |
21:17:34 | Varriount | flaviu: Hm? |
21:18:26 | Varriount | Araq: The koch version issue is fixed. |
21:18:59 | flaviu | Varriount: You can record macros with vim |
21:19:18 | flaviu | I just navigated to every definition and pressed @@ to replay the macro |
21:22:02 | Araq | Varriount: --threads:on with 'cpp' doesn't work. you can look into that |
21:23:02 | ldlework | what's the best emacs nimrod-mod? |
21:23:05 | ldlework | mode* |
21:23:08 | * | xcombelle quit (Ping timeout: 255 seconds) |
21:38:57 | * | xenagi joined #nimrod |
21:52:11 | * | enurlyx joined #nimrod |
21:53:21 | will | ldlework: not sure, but some emacs plugins can be found on https://github.com/Araq/Nimrod/wiki/Editor-Support |
21:54:10 | flaviu | ldlework: https://github.com/reactormonk/nimrod-mode/network ; choose the one with the most commits |
21:56:07 | enurlyx | Did the rules for 'extern' change? It seems with bigbreak it is not possible to export an imported lib. |
21:56:18 | enurlyx | extern -> export |
21:57:08 | Varriount | enurlyx: I don't know. Can you use git bisect? |
21:58:46 | enurlyx | I do not know that tool. I can do it by hand ... |
21:59:06 | Varriount | Araq: c:\64\nimrod\nimcache\stdlib_os.cpp: In function 'void getenvvarsc_125405()': |
21:59:06 | Varriount | c:\64\nimrod\nimcache\stdlib_os.cpp:861:32: error: invalid conversion from 'NI16* {aka short int*}' to 'const wchar_t*' [-fpermissive] |
21:59:06 | Varriount | eend = wcschr(e, ((NI32) 0)); |
22:01:08 | Varriount | Araq: there are more errors, most being associated with being unable to convert one data type to another. |
22:03:20 | Varriount | In fact, I get those even without threading enabled. |
22:03:55 | Araq | Varriount: well -fpermissive is supposed to suppress these |
22:04:53 | Varriount | But it's not..? |
22:05:17 | Araq | it seems to depend on the gcc version ... |
22:08:12 | * | superfunc joined #nimrod |
22:09:19 | Varriount | Araq: I'll test the 32 bit version then. |
22:11:56 | Varriount | Araq: I get the same errors using a 32 bit C compiler. |
22:26:22 | Araq | Varriount: you mean c++ compiler, right? |
22:26:51 | Varriount | Er yeah. |
22:27:08 | Varriount | Araq: For some reason the Nim compiler isn't passing -fpermissive |
22:27:32 | Varriount | Not even when I pass it via '--passC:"-fpermissive"' |
22:28:10 | Araq | are you on devel or bigbreak? |
22:29:56 | Varriount | I'm on bigbreak. |
22:31:21 | * | johnsoft quit (Ping timeout: 258 seconds) |
22:31:41 | * | johnsoft joined #nimrod |
22:33:36 | Varriount | Araq: Does your build of the Nim compiler pass the -fpermissive option? |
22:34:39 | Araq | dunno, will tell you later, I'm busy with benign |
22:40:48 | * | superfunc__ joined #nimrod |
22:51:15 | Varriount | Hi superfunc |
22:51:32 | superfunc__ | Yo |
22:59:00 | fowl | whats benign? a game? |
23:04:42 | flaviu | fowl: nope, check the logs |
23:06:16 | superfunc__ | does anyone know of a container which guarantees uniqueness of elements but preserves insertion order? |
23:07:24 | superfunc__ | I suppose a hash table with a value type of (insertion_pos, actual_value) could do that |
23:09:51 | reactormonk | cool |
23:10:24 | superfunc__ | I was surprised I couldn't find a container that has that in the STL |
23:12:29 | reactormonk | ldlework, I just pulled lyro's changes as well, thanks |
23:12:48 | Araq | superfunc__: nim has (T)OrderedTable for that |
23:13:25 | superfunc__ | thanks Araq, I was needing it for a c++ project I have to do |
23:21:12 | Varriount | superfunc: You're using Nim for a C++ project? |
23:21:22 | Varriount | Is that even allowed? |
23:22:57 | superfunc | Nah, I was just asking a general data structure question. My compilers professor lets us use anything, so long as we provide a simple make file, so I have been using nim for that |
23:23:28 | superfunc | Lol, everytime he gets my hw, the script rebuilds nim |
23:24:59 | Varriount | Hm. Too bad your professor couldn't assign an asignment like, say, "Study the Nim compiler source code, and fix an error or create an addition" |
23:26:43 | Varriount | Araq: Searching through the compiler source for 'permissive' doesn't bring up anything |
23:27:12 | Araq | Varriount: it's only set in the config |
23:29:03 | Varriount | Araq: In the config, -fpermissive is only set for macosx |
23:30:35 | Araq | Varriount: in my config there is an @else |
23:30:42 | Araq | and I just remembered |
23:30:47 | superfunc | I would like to contribute when I understand compilers better |
23:30:58 | Araq | there is bug entry for --passC not working for cpp |
23:41:32 | flaviu | superfunc: Compilers are super simple! They are just string -> AST (-> AST)* -> target :P |
23:42:09 | Varriount | superfunc: As demonstrated by the wonderfully simple and easy to understand Nim compiler! |
23:42:23 | flaviu | ;) |
23:42:49 | Varriount | Araq: Well, my configuration file has the @else part, however it's still not working. |
23:43:22 | superfunc__ | flaviu: lol |
23:44:24 | Araq | Varriount: check extccomp.nim, it sometimes resets stuff |
23:44:29 | flaviu | superfunc__: It'd be even easier if were writing compilers a few tens of years ago! Just string -> target! |
23:44:58 | Araq | flaviu: on unix, it's even easier: string -> string |
23:46:06 | flaviu | Araq: string ∈ possible targets |
23:46:27 | Araq | nah, there is nothing better than an untyped stream of bytes |
23:47:19 | Araq | which we call "file" (a nice euphemism) |
23:48:36 | superfunc__ | lol |
23:48:50 | flaviu | And main memory is also a stream of untyped bytes! We need lots of external machinery to make sure everything lines up correctly. Major design flaw in all known OSes! |
23:50:09 | Varriount | Araq: Could this bug be due to the fact that g++ command line options are presented in the config file using 'gpp'? |
23:50:48 | Varriount | There doesn't seem to be anything in the compiler code mapping 'gpp' to 'g++' |
23:54:40 | Araq | flaviu: ever redirected some output that uses escape sequences? the truth is that Unix even sucks at the things it's supposedly very good at. |
23:55:32 | flaviu | I've redirected gigs of /dev/urandom, I assume that'll contain at least one escape sequence? |
23:59:35 | Varriount | Araq: Eh... the config file is wrong. |