| 00:00:42 | * | devdri_ quit (Ping timeout: 276 seconds) |
| 00:05:55 | flaviu1 | Demos_: Yes |
| 00:09:49 | * | flaviu1 quit (Read error: Connection reset by peer) |
| 00:10:05 | * | flaviu1 joined #nimrod |
| 00:13:26 | * | brson quit (Ping timeout: 240 seconds) |
| 00:13:41 | flaviu1 | Demos_: Did I break things? |
| 00:14:10 | Demos_ | Looking at the changes I see that you .toLower the first character, if I change this to toUpper I get all kinds of errors related to c identifiers not being around |
| 00:14:10 | * | q66 quit (Quit: Leaving) |
| 00:14:16 | Demos_ | and yeah a little bit |
| 00:14:33 | Demos_ | you can now generate c keywords as ident names |
| 00:15:46 | * | brson joined #nimrod |
| 00:22:37 | Demos_ | interestingly the idents I get errors about have lowercase letters as their first char |
| 00:24:35 | flaviu1 | Demos_: I think I kept everything the same, toLower was always there, it was just disguised as `chr(ord(name[i]) - ord('A') + ord('a'))` |
| 00:26:14 | EXetoC | pretty |
| 00:27:23 | Demos_ | it was add(result, chr(ord(name[0]) - ord('a') + ord('A'))) before I think |
| 00:29:04 | Demos_ | well that is only active if the char was lowercase beforehand |
| 00:29:22 | flaviu1 | That was behind a when false in the `mangle()` method and kept in the `mangleField()` method. Has your code worked before? |
| 00:30:42 | Demos_ | ues |
| 00:30:44 | Demos_ | yea |
| 00:31:00 | Demos_ | oh |
| 00:31:06 | Demos_ | I see that when false |
| 00:31:15 | flaviu1 | Maybe I messed up on some subtle behavior. |
| 00:31:50 | Demos_ | try naming a field union or Union |
| 00:33:51 | flaviu1 | Demos_: I can't reproduce it |
| 00:34:03 | flaviu1 | wait, I havent pulled |
| 00:34:14 | * | EXetoC quit (Quit: WeeChat 0.4.3) |
| 00:37:54 | flaviu1 | Demos_: Yeah, I can't reproduce it. `let union = true` with just c as the compiler options? |
| 00:39:02 | Demos_ | oh shit |
| 00:40:04 | flaviu1 | bbl |
| 00:45:48 | Demos_ | ugh I can not repro it either |
| 00:46:23 | Demos_ | except on the 20kloc file that it breaks |
| 00:51:59 | * | Demos_ quit (Ping timeout: 258 seconds) |
| 00:59:26 | * | hoverbear joined #nimrod |
| 01:39:08 | * | brson_ joined #nimrod |
| 01:41:26 | * | brson quit (Ping timeout: 258 seconds) |
| 01:51:02 | * | hoverbea_ joined #nimrod |
| 01:57:14 | * | untitaker_ joined #nimrod |
| 01:58:36 | * | hoverbear quit (*.net *.split) |
| 01:58:37 | * | untitaker quit (*.net *.split) |
| 02:06:20 | * | freezerburnv joined #nimrod |
| 02:07:25 | * | freezerburnv quit (Client Quit) |
| 02:08:17 | * | BitPuffin quit (Ping timeout: 252 seconds) |
| 02:10:36 | * | ehaliewicz joined #nimrod |
| 02:57:32 | * | BitPuffin joined #nimrod |
| 03:29:54 | * | xenagi quit (Quit: Leaving) |
| 03:40:22 | CARAM_ | how does the GC deal with say, an proc you import through FFI? |
| 03:41:46 | CARAM_ | like if I call a c function that allocates and then returns a ref for a struct, is there any way for that to get picked up by the GC? |
| 03:46:06 | fowl | CARAM_, you mean it allocates and returns a pointer? |
| 03:46:16 | CARAM_ | yes |
| 03:46:32 | fowl | you can box it in a reference |
| 03:49:46 | CARAM_ | so the struct will get GC'd? |
| 03:50:14 | CARAM_ | or do I need to manually dealloc it? |
| 03:50:18 | fowl | most c apis are exposed as bare as possible though, requiring you to call destroy() or something similar when you're done with it |
| 03:50:30 | fowl | CARAM_, yea, ref types are gc'd |
| 03:51:36 | CARAM_ | oh sweet |
| 03:52:05 | CARAM_ | thanks |
| 03:53:06 | CARAM_ | and do you know if I was interested in accessing the members of that struct, would that be possible? |
| 03:53:35 | fowl | yea |
| 03:55:24 | CARAM_ | how would I do that? |
| 03:55:56 | fowl | heres an example https://gist.github.com/fowlmouth/950c998b7de5f9663af5 |
| 03:57:16 | fowl | CARAM_, you need the layout of the struct to match whatever comes from the DLL you're calling into |
| 03:59:36 | CARAM_ | gotcha, thanks! |
| 04:05:41 | * | flaviu1 quit (Remote host closed the connection) |
| 04:14:10 | * | brson_ quit (Quit: leaving) |
| 04:23:37 | * | xtagon joined #nimrod |
| 04:31:52 | * | Demos_ joined #nimrod |
| 04:36:08 | Demos_ | I found the repro for the union thing |
| 04:36:13 | Demos_ | will tell about it tomorrow |
| 04:42:30 | fowl | i know what im dreaming about tonight (: |
| 04:45:49 | * | Demos_ quit (Ping timeout: 258 seconds) |
| 04:53:08 | * | xtagon quit (Quit: Leaving) |
| 06:04:20 | * | devdri joined #nimrod |
| 06:06:03 | * | hoverbea_ quit () |
| 06:08:59 | * | devdri quit (Ping timeout: 252 seconds) |
| 06:57:39 | NimBot | Araq/Nimrod new_spawn d2dbcf2 Araq [+3 ±5 -2]: progress with futures |
| 07:22:58 | Varriount | dom96: On linux, what happens when an inotify watch is renamed? |
| 07:23:52 | Varriount | dom96: Also, when watching a directory, are events for the directory itself reported, or just events from the files in the directory? |
| 07:26:40 | * | nande_ quit (Remote host closed the connection) |
| 07:28:37 | * | EXetoC joined #nimrod |
| 07:45:34 | Varriount | Araq: Any relatively easy compiler bugs I can bang my head against? |
| 07:51:09 | Araq | Varriount. I never know about the "easy" but surely |
| 07:52:28 | Varriount | Araq: Let me rephrase. Could you give me a compiler bug that's possible for me to solve in 1-3 days, with possibly a hint as to where I should be looking to fix the bug? |
| 07:52:48 | Araq | dude wait a sec |
| 07:52:54 | Araq | I'm looking up the bug number |
| 07:54:12 | Araq | bug #1200 is easy |
| 07:54:24 | Araq | just make renderParamTypes more robust |
| 07:57:01 | Araq | possibly by using lookups.considerAcc() |
| 07:58:14 | Araq | also have a look at bug #1011 |
| 07:58:33 | Araq | this is not that easy to fix, but it's really embarrassing |
| 07:59:14 | Araq | semtempl.nim needs special handling for nkDotExpr (the AST that represents obj.field) |
| 07:59:44 | * | njoejoe quit (Ping timeout: 276 seconds) |
| 08:00:21 | Varriount | Ok, I'll work on those. |
| 08:11:25 | Varriount | Huh, the whole word "consider" comes up 23 times in the compiler source code (just comments) |
| 08:13:38 | EXetoC | 78 case-insensitive matches |
| 08:13:49 | EXetoC | oh comments |
| 08:14:08 | EXetoC | once again I've read too quickly |
| 08:14:54 | EXetoC | 25 times then :p |
| 08:20:19 | Araq | Varriount: remind me to skype with you about bug #1011 |
| 08:21:43 | Araq | I need to explain to you the details of symbol choice lists |
| 08:26:10 | * | Varriount|Mobile quit (Remote host closed the connection) |
| 08:26:25 | * | Varriount|Mobile joined #nimrod |
| 08:28:02 | * | devdri joined #nimrod |
| 08:38:02 | * | kunev joined #nimrod |
| 08:55:59 | * | Varriount|Mobile quit (Read error: Connection reset by peer) |
| 08:56:40 | * | Varriount-Mobile joined #nimrod |
| 09:18:38 | dom96 | Varriount: inotify watches have names? |
| 09:18:56 | dom96 | Varriount: It's been a long time and I can't remember. |
| 09:19:14 | dom96 | Varriount: Is the windows implementation done? |
| 09:27:56 | Varriount | dom96: 98% done |
| 09:28:21 | Varriount | dom96: I need to know how to handle watched files being moved/renamed |
| 09:28:41 | * | devdri quit () |
| 09:28:48 | dom96 | EventMoved? |
| 09:29:10 | dom96 | Actually, EventRenamed is better. |
| 09:29:14 | Varriount | dom96: Remember that Windows only allows monitoring directory contents, not a single file. |
| 09:29:40 | Varriount | dom96: Therefore, to implement file level monitoring, I have to implement a filter. |
| 09:30:59 | * | io2 joined #nimrod |
| 09:34:20 | Varriount | dom96: https://github.com/Varriount/Nimrod/blob/os/filemon/lib/pure/filemon.nim |
| 09:36:17 | Varriount | dom96: If you look at the watchFile procedure, I have to add an additional wrapper callback to filter out events concerning other files. |
| 09:38:57 | dom96 | huh, how does this work. Why doesn't watchFile take an fd as its first arg or something? |
| 09:39:09 | Araq | filemon is a cool name |
| 09:39:31 | Araq | I used to search for Mons |
| 09:39:52 | Araq | even had to fight a Gorgor to get one :p |
| 09:39:58 | dom96 | Also, these procs should return a future |
| 09:40:22 | Araq | but not a threadpool.future ... |
| 09:40:25 | Varriount | dom96: A future only fires ones? |
| 09:40:30 | Varriount | *once |
| 09:40:44 | Araq | we really need a name for that |
| 09:41:06 | Araq | promise? delayed? dataflow? flow? |
| 09:41:09 | dom96 | Varriount: Good point, hrm. |
| 09:41:26 | Varriount | dom96: I could add future support I think. |
| 09:41:29 | dom96 | Araq: No, there should be no distinction! You should reuse my futures! |
| 09:41:43 | Araq | dom96: no way |
| 09:41:53 | Araq | though .. hrm |
| 09:42:00 | Varriount | dom96: I'll think on it when I take my shower. |
| 09:42:25 | dom96 | But more importantly, there should be a FileMonitor object keeping state or something |
| 09:42:33 | Varriount | dom96: No... |
| 09:43:06 | Varriount | There isn't really any state that needs to be kept, that isn't kept in the closure already. |
| 09:43:25 | dom96 | inotify will likely need it |
| 09:44:49 | dom96 | I guess using callbacks is fine. |
| 09:45:00 | dom96 | But you need to make the callback return a PFuture[bool] |
| 09:46:31 | Varriount | dom96: Er, you do know that the callback returns a bool in order to signal whether to stop watching a directory, right? |
| 09:47:21 | dom96 | does that matter? |
| 09:47:29 | dom96 | The point is I should be able to await inside that callback |
| 09:48:12 | * | io2 quit (Quit: ...take irc away, what are you? genius, billionaire, playboy, philanthropist) |
| 09:48:34 | Varriount | dom96: Have you read the entire source code? |
| 09:48:48 | * | Jehan_ joined #nimrod |
| 09:50:04 | dom96 | no |
| 09:50:26 | Varriount | Let me add some comments then. |
| 09:51:07 | dom96 | You simply add a callback to the future returned by the FileEventCb |
| 09:51:28 | dom96 | it should be possible to cancel the watch asynchronously |
| 09:52:09 | Varriount | dom96: Yes, I was planning to do that via a handle to the actual watch |
| 09:52:55 | dom96 | If you don't make the callback asynchronous I won't be able to do much in the callback |
| 09:53:23 | dom96 | say for example I want to read the file that was modified |
| 09:53:43 | dom96 | how do I do that asynchronously if the callback needs to return immediately? |
| 09:54:57 | Jehan_ | I'm not sure that I understand what you need to do? |
| 09:57:42 | Varriount | dom96: Then wouldn't you put that logic in the callback itself? |
| 09:57:58 | dom96 | exactly |
| 09:58:07 | dom96 | But how do I do that when the callback isn't asynchronous? |
| 09:58:25 | Varriount | What do you mean by asynchronous? |
| 09:58:41 | dom96 | returning PFuture |
| 09:58:50 | dom96 | and therefore not completing immediately. |
| 09:59:07 | Varriount | It is called every time asyncdispatch.poll() is called and there are file events waiting. |
| 09:59:40 | dom96 | I know. But if I want to use an {.async.} proc as a callback I am shit out of luck. |
| 10:01:40 | EXetoC | can it be non-blocking or must a thread be spawned? |
| 10:01:50 | Varriount | dom96: I'll make the change. I don't know how it will work, but I'll do it. |
| 10:02:28 | Varriount | dom96: Which procedure(s) need to return a future, and of what kind? |
| 10:03:20 | dom96 | just the file event callback |
| 10:04:51 | dom96 | It may be simpler to just get rid of its return value |
| 10:05:15 | dom96 | You can create a delWatch instead |
| 10:06:21 | Varriount | dom96: You've seen the fileEventCb inside watchPathImpl, right? |
| 10:06:43 | dom96 | yes, i'm looking at it |
| 10:06:49 | EXetoC | and if you had to create a thread for example, then it wouldn't be a good idea to use async, right? |
| 10:07:04 | Varriount | EXetoC: It doesn't use threads. |
| 10:07:17 | dom96 | it will use threads eventually |
| 10:07:30 | dom96 | which may be another reason to introduce a FileMonitor object |
| 10:08:02 | dom96 | but I dunno |
| 10:08:10 | dom96 | Haven't worked out the details with that yet |
| 10:08:41 | Varriount | dom96: If in doubt, look at what successful async implementations in other languages have done, and do what they do. |
| 10:08:48 | EXetoC | when? using a thread and pretending that something doesn't block seems silly |
| 10:09:06 | Varriount | Or rather, do what they do well, and do better what they don't do well. |
| 10:09:07 | dom96 | EXetoC: So that it can use all cores. |
| 10:09:42 | dom96 | Varriount: Yeah, you should get rid of the return value. |
| 10:09:58 | dom96 | And then simply call ``callBack`` |
| 10:10:12 | Varriount | Yeth Mathter. |
| 10:10:28 | dom96 | Make it return a PFuture[void] and the dispatcher will take care of the rest ;) |
| 10:10:45 | Araq | hi Jehan_ I've implemented "futures" (we really need another name) in the new_spawn branch |
| 10:11:08 | Varriount | dom96: Now I have no way to stop watching files/directories. |
| 10:11:21 | dom96 | Varriount: What about a removeWatch proc? |
| 10:11:38 | Araq | and the 5 line trivial test program doesn't crash, but a code review would really be nice ... |
| 10:11:47 | Varriount | dom96: Yeah, but now I need to store the handle somewhere. |
| 10:12:02 | dom96 | Varriount: FileMonitor object ;) |
| 10:12:29 | Varriount | *grumble* *grumble* |
| 10:13:29 | Varriount | dom96: Shoud I move the closure to per-filemonitor, instead of per-watch? |
| 10:13:34 | Varriount | *Should |
| 10:14:15 | dom96 | hrm. Per-filemonitor I think |
| 10:18:01 | Varriount | dom96: Part of me dislikes the fact that much of the information that will be contained in the FileMonitor object is also contained in the global dispatcher |
| 10:18:53 | * | BitPuffin quit (Ping timeout: 252 seconds) |
| 10:20:13 | EXetoC | dom96: so the purpose is not just to optionally block with await? I've only used it for serial tasks with non-blocking sockets |
| 10:21:02 | dom96 | EXetoC: The purpose of await is to delegate control to other async procs |
| 10:21:20 | Varriount | Using the magic of iterators! |
| 10:22:15 | EXetoC | yeah ok. my usage is much simpler |
| 10:22:28 | dom96 | Varriount: Actually, the dispatcher needs an unregister proc |
| 10:23:14 | dom96 | and you should call it |
| 10:23:18 | dom96 | why do you need a handle list? |
| 10:24:20 | Varriount | dom96: I need to map filenames to handles, so that external procs can cancel file watching |
| 10:24:27 | EXetoC | 'when' as expression ftw |
| 10:24:52 | dom96 | EXetoC: Using all cores is useful for socket servers. So that they scale well. |
| 10:24:56 | Varriount | dom96: The only way to cancel file watching on windows is to call CancelIo(directoryHandle) |
| 10:25:08 | EXetoC | sure |
| 10:25:31 | dom96 | oh no. You should return the handle. |
| 10:25:42 | dom96 | And pass that to removeWatch |
| 10:27:01 | Varriount | dom96: And where will that handle come from? |
| 10:27:12 | dom96 | watchFile/dir? |
| 10:27:36 | Varriount | dom96: Aren't those supposed to return futures? |
| 10:27:45 | dom96 | nah |
| 10:28:05 | Varriount | Then where will the futures be sent? |
| 10:28:12 | dom96 | Do they perform anything which can block? |
| 10:28:25 | dom96 | if the answer is no then they shouldn't return futures |
| 10:28:39 | dom96 | you mean the one from the FileEventCb? |
| 10:28:43 | Varriount | dom96: Yes. |
| 10:28:47 | dom96 | it will be discarded |
| 10:29:00 | Varriount | So I'm creating a future... only to discard it? |
| 10:29:02 | * | dom96 is quite proud of how awesomely magically this works :P |
| 10:29:15 | dom96 | Yes, because it returns void anyway. |
| 10:29:29 | dom96 | The future will still complete, but you do not need to wait until it does |
| 10:29:35 | dom96 | So you simply discard it |
| 10:29:50 | * | dom96 needs to explain this in his blog post if he hasn't already |
| 10:29:51 | Varriount | dom96: I'd like to discuss this further (on teamspeak if possible), however I need to take a shower. |
| 10:29:59 | dom96 | ok, I need to eat something |
| 10:30:05 | Varriount | I'll be back in about 20-30 minutes |
| 10:30:08 | dom96 | k |
| 10:41:12 | Araq | a shower really shouldn't take 30 minutes |
| 10:41:30 | EXetoC | 5 maybe |
| 10:43:48 | EXetoC | dom96: well, sockets don't block, but I guess that's an exception |
| 10:46:00 | dom96 | what? sockets do. |
| 10:46:44 | * | ehaliewicz quit (Ping timeout: 252 seconds) |
| 10:49:15 | EXetoC | I don't know how it's considered asynchronous if it's not being processed in a separate thread |
| 10:55:13 | dom96 | Multithreading and asynchronous IO are two different things. |
| 10:55:22 | Araq | EXetoC: it doesn't block so the thread can continue with other stuff |
| 10:55:23 | dom96 | The latter does not require threads. |
| 10:55:32 | dom96 | brb need to walk dog. |
| 10:56:26 | EXetoC | it doesn't block in any way still |
| 11:04:18 | Varriount | dom96: I'm on teamspeak |
| 11:08:03 | EXetoC | dom96: you mean they *might* block? or maybe the term is used in different ways, which would be confusing |
| 11:08:32 | * | BitPuffin joined #nimrod |
| 11:08:44 | Varriount | EXetoC: Asynchrous IO means that an IO operation is not done all at once. Rather, it is spread out. |
| 11:53:01 | * | Matthias247 joined #nimrod |
| 12:12:01 | NimBot | Araq/Nimrod devel 6a38d36 Dominik Picheta [+0 ±3 -0]: Rename asyncdispatch.close to asyncdispatch.closeSocket. |
| 12:13:31 | * | untitaker_ quit (Ping timeout: 240 seconds) |
| 12:13:37 | Araq | dom96: why the rename? |
| 12:14:33 | dom96 | It'll become ambiguous when I introduce file i/o |
| 12:14:55 | dom96 | also the name doesn't reflect what the proc does |
| 12:18:40 | * | untitaker joined #nimrod |
| 12:21:43 | Araq | does this break code? |
| 12:22:28 | * | askatasuna quit (Ping timeout: 252 seconds) |
| 12:22:50 | dom96 | Yes. But no sane person should be using that module. |
| 12:26:24 | * | Jehan_ quit (Quit: Leaving) |
| 12:34:26 | Araq | ok then |
| 12:35:55 | * | Vendethiel- quit (Read error: Connection reset by peer) |
| 12:39:07 | * | vendethiel joined #nimrod |
| 12:39:47 | * | askatasuna joined #nimrod |
| 12:46:15 | * | darkf quit (Quit: Leaving) |
| 12:48:55 | * | nande_ joined #nimrod |
| 12:50:45 | * | devdri joined #nimrod |
| 12:57:23 | NimBot | Araq/Nimrod devel 657a000 Billingsly Wetherfordshire [+0 ±1 -0]: `=>` macro tripped on generic return types... 2 more lines |
| 12:57:23 | NimBot | Araq/Nimrod devel c6c7c65 Dominik Picheta [+0 ±1 -0]: Merge pull request #1209 from fowlmouth/patch-3... 2 more lines |
| 13:08:05 | * | Varriount-Mobile quit (Ping timeout: 264 seconds) |
| 13:11:45 | * | askatasuna quit (Quit: WeeChat 0.4.3) |
| 13:12:14 | * | wan quit (Ping timeout: 240 seconds) |
| 13:12:43 | * | wan joined #nimrod |
| 13:20:06 | * | Jehan_ joined #nimrod |
| 13:28:07 | * | vendethiel quit (Read error: Connection reset by peer) |
| 13:31:02 | * | devdri quit () |
| 13:31:50 | * | Varriount-Mobile joined #nimrod |
| 13:36:24 | * | vendethiel joined #nimrod |
| 14:02:35 | * | devdri joined #nimrod |
| 14:05:13 | OrionPK | hola guys |
| 14:05:30 | Varriount | Hi OrionPK, long time no see. |
| 14:05:39 | OrionPK | I've been lurkin around |
| 14:05:44 | OrionPK | how've you been |
| 14:06:11 | Varriount | OrionPK: I got a job! |
| 14:06:17 | OrionPK | congrats! |
| 14:06:23 | OrionPK | doing what? |
| 14:16:06 | * | devdri quit () |
| 14:19:59 | * | hoverbear joined #nimrod |
| 14:24:03 | * | hoverbear quit (Client Quit) |
| 14:32:11 | * | devdri joined #nimrod |
| 14:34:35 | Varriount | dom96: Added a rule concerning multi-line procedure calls. https://github.com/Araq/Nimrod/wiki/NEP-1 |
| 14:36:01 | * | Varriount-Mobile quit (Quit: AndroIRC - Android IRC Client ( http://www.androirc.com )) |
| 14:37:15 | * | devdri quit () |
| 14:43:26 | dom96 | Varriount: looks good |
| 14:44:31 | * | core-ix joined #nimrod |
| 14:44:51 | Varriount | Hello core-ix |
| 14:45:03 | * | boydgreenfield joined #nimrod |
| 14:45:09 | * | devdri joined #nimrod |
| 14:49:40 | Varriount | Hello devdri |
| 14:49:55 | devdri | hi |
| 14:51:22 | * | kunev quit (Quit: leaving) |
| 14:55:01 | * | devdri quit () |
| 14:55:51 | Varriount | Araq: What does 'considerAcc' stand for? Consider access? |
| 15:04:40 | * | tiffer joined #nimrod |
| 15:05:10 | * | tiffer left #nimrod (#nimrod) |
| 15:19:31 | * | noam_ joined #nimrod |
| 15:22:48 | * | noam quit (Ping timeout: 255 seconds) |
| 15:45:56 | * | flaviu1 joined #nimrod |
| 15:52:14 | * | JehanII joined #nimrod |
| 15:52:15 | * | Jehan_ quit (Read error: Connection reset by peer) |
| 15:52:22 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 15:55:05 | * | io2 joined #nimrod |
| 16:12:51 | * | hoverbear joined #nimrod |
| 16:28:44 | * | njoejoe joined #nimrod |
| 16:41:15 | * | hoverbear quit () |
| 16:41:38 | * | hoverbear joined #nimrod |
| 16:41:44 | * | hoverbear quit (Max SendQ exceeded) |
| 16:42:24 | * | hoverbear joined #nimrod |
| 16:44:55 | * | hoverbear quit (Client Quit) |
| 16:48:41 | * | Demos_ joined #nimrod |
| 16:58:44 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 17:10:05 | * | q66 joined #nimrod |
| 17:10:05 | * | q66 quit (Changing host) |
| 17:10:05 | * | q66 joined #nimrod |
| 17:26:37 | Araq | Varriount: "consider the ` ` notation" ("accent") |
| 17:27:58 | * | core-ix quit (Remote host closed the connection) |
| 17:28:46 | * | hoverbear joined #nimrod |
| 17:32:14 | * | brson joined #nimrod |
| 17:44:21 | OrionPK | araq have you looked into the vm issue? |
| 17:44:57 | flaviu1 | dom96: Do I just dig the rst module out of the compiler for nimforum? |
| 17:45:51 | dom96 | you likely need to change this https://github.com/nimrod-code/nimforum/blob/master/nimrod.cfg#L3 |
| 17:47:16 | flaviu1 | dom96: I'm switching things over to babel since I have to use a babel package anyway, I think that I'll try to pull docutils into a babel package |
| 17:49:58 | * | xtagon joined #nimrod |
| 17:50:01 | Demos_ | hey flaviu1 to rpro that bug just make sure to make an object with a member named Union and then make an exported proc that takes it as a param |
| 17:50:16 | Demos_ | otherwise the whole object will not get put in the generated code |
| 17:50:38 | flaviu1 | Demos_: Thanks, I'll look into it in a few minutes |
| 17:50:43 | Demos_ | k |
| 17:50:57 | Demos_ | it should be an easy fix but I do not know my way around that part of the compiler |
| 18:01:53 | flaviu1 | dom96: I made a pull request for docutils on nimrod-code/packages, can you merge it? |
| 18:02:48 | dom96 | Maybe you should ask Araq what he thinks before you do that. |
| 18:02:53 | dom96 | The compiler depends on this after all. |
| 18:03:52 | Araq | flaviu1: the compiler depends on it, so it doesn't make sense to make it a babel package. You're not the first guy with that idea... |
| 18:04:38 | Araq | we should make "nimrod doc|doc2" a separate .exe and then can babelize it |
| 18:04:51 | flaviu1 | Araq: Can I fork it, call it 'rstparser', and have it be a babel lib> |
| 18:04:57 | Araq | but oh ... reality is more complex than that |
| 18:05:12 | flaviu1 | s/>/?/ |
| 18:05:24 | Araq | let's see ... can idetools export the generated docs? you bet. |
| 18:05:40 | Araq | so "nimrod idetools" should be separate too ... |
| 18:07:12 | * | hoverbea_ joined #nimrod |
| 18:10:03 | Araq | flaviu1: you can do that, but what's the problem? that you have no compiler around to compile nimforum? |
| 18:11:22 | flaviu1 | Araq: I like the idea of it being completely self-contained, but if you don't want docutils in babel, I can use the compiler sources without problem |
| 18:11:23 | * | hoverbear quit (Ping timeout: 276 seconds) |
| 18:13:48 | * | icebattl1 is now known as icebattle |
| 18:22:26 | * | Mat3 joined #nimrod |
| 18:22:29 | Mat3 | hello |
| 18:22:30 | EXetoC | meep |
| 18:22:38 | EXetoC | timing. hi Mat3 |
| 18:22:52 | EXetoC | did you go offline to finish what we talked about? |
| 18:22:59 | Mat3 | hi EXetoC |
| 18:24:47 | Araq | OrionPK: can look at it again tonight, sorry |
| 18:25:33 | Mat3 | EXetoC: I've finished the native-code compiler, yes. At current working on the backends and an IL which can be used instead C by the Nimrod compiler |
| 18:26:59 | Araq | Mat3: nice. let me know if you need any help with anything, testing for instance. :D |
| 18:27:09 | Mat3 | (because I've already have a implementation stub of these language written in C chances exist this do not take much time) |
| 18:28:12 | Mat3 | Araq: will do |
| 18:28:18 | flaviu1 | dom96: Which version of jester do you use on nimforum? The latest (I think) has some issues with macros |
| 18:30:28 | OrionPK | araq cool |
| 18:33:35 | Araq | you guys should check out the new_spawn branch btw. Multi-threading has never been easier in Nimrod. |
| 18:33:36 | Mat3 | Araq: There will exist a bare-metal version of it which I code in x86-64 beside. Because most UEFI firmwares seem to be very bug ridden (and secure boot a bizarre desperation) some testing on real hardware would be fine for example |
| 18:43:26 | * | Mat3 is now known as Mat3-coding |
| 18:45:22 | Araq | Mat3-coding: well it's not real backend until it can bootstrap the compiler ;-) |
| 18:46:23 | Araq | bbl |
| 18:46:52 | Araq | Varriount: don't pull that parseFloat enhancement, it breaks CTFE |
| 18:46:54 | Araq | bbl |
| 18:47:41 | flaviu1 | Float parsing is a mess |
| 18:49:13 | flaviu1 | You have to do all sorts of bit manipulations to get good results, otherwise your floats won't be accurate. Unless you're java, in which case you have to do everything with regular float operations, which is even more compilcated |
| 18:50:23 | * | JehanII quit (Read error: Connection reset by peer) |
| 18:50:33 | * | Jehan_ joined #nimrod |
| 18:51:14 | dom96 | flaviu1: The latest |
| 18:52:35 | * | JehanII joined #nimrod |
| 18:52:36 | * | Jehan_ quit (Read error: Connection reset by peer) |
| 18:54:28 | * | hoverbea_ quit () |
| 19:10:08 | flaviu1 | using a hashed password as a session ID really isn't a good idea, but its worst implication is that an account could be taken over if someone gets access to that cookie |
| 19:18:43 | Mat3-coding | the forum get hacked ? |
| 19:19:13 | flaviu1 | Mat3-coding: No |
| 19:20:03 | flaviu1 | I'm just going over the code for obvious vulnerabilities. |
| 19:25:24 | flaviu1 | I don't understand this error: 'macros.nim(330, 21) Error: type mismatch: got (int literal(2), string) but expected one of: ...' with `&`. That line doesn't even contain a call to `&` |
| 19:27:27 | EXetoC | wrong line maybe |
| 19:29:41 | flaviu1 | I don't think so, the surrounding lines don't have a `&` either |
| 19:30:44 | EXetoC | :O |
| 19:31:13 | dom96 | yeah, those errors are no fun. |
| 19:31:19 | dom96 | Is that what keeps jester from compiling? |
| 19:32:04 | flaviu1 | dom96: No, it isn't in jester |
| 19:32:23 | flaviu1 | Its in bcrypt, I think. I can't reproduce it except with the new hasing |
| 19:32:39 | flaviu1 | nm, it isn't bcrypt |
| 19:33:39 | flaviu1 | dom96: BTW, you might get better performance by adding `and password = ?` to the query, but its probably insignificant. |
| 19:38:16 | * | nande_ quit (Read error: Connection reset by peer) |
| 19:41:20 | flaviu1 | dom96: It actually may be jester, but it already had hinted that jester was compiled, I'm not sure |
| 19:42:10 | dom96 | flaviu1: Does it happen without your changes to nimforum? |
| 19:42:49 | flaviu1 | dom96: Yes |
| 19:43:43 | dom96 | I guess that's a regression then :\ |
| 19:43:48 | flaviu1 | I wonder how stable nimrod works |
| 19:47:42 | Mat3-coding | I think nil is now deprecated, right ? If so, what's the current replacement |
| 19:51:06 | EXetoC | it's only deprecated as a placeholder for an empty function, where discard should be used instead |
| 19:51:26 | EXetoC | or a comment, but that'll go away |
| 19:53:17 | Mat3-coding | thanks |
| 19:55:28 | EXetoC | I mean block |
| 20:26:18 | flaviu1 | dom96: Ok, pull request sent. You have to pre-process the database to update all the hashes, my untested code for doing that is in the pull request |
| 20:26:42 | dom96 | did you fix the jester issue? |
| 20:26:45 | flaviu1 | Also, I couldn't compile it, so it may break everything |
| 20:26:59 | flaviu1 | No, I couldn't compile the older version of nimrod for some reason |
| 20:30:53 | * | hoverbear joined #nimrod |
| 20:43:29 | * | BitPuffin quit (Ping timeout: 276 seconds) |
| 20:53:14 | * | Mat3-coding quit (Ping timeout: 276 seconds) |
| 21:12:28 | * | Matthias247 joined #nimrod |
| 21:25:43 | * | Varriount_ joined #nimrod |
| 21:27:02 | * | Varriount quit (Ping timeout: 240 seconds) |
| 21:33:27 | * | nande_ joined #nimrod |
| 21:50:14 | * | JehanII quit (Read error: Connection reset by peer) |
| 21:50:36 | * | Jehan_ joined #nimrod |
| 21:52:49 | * | Jehan_ quit (Read error: Connection reset by peer) |
| 21:53:12 | * | Jehan_ joined #nimrod |
| 22:02:58 | * | BitPuffin joined #nimrod |
| 22:19:53 | * | Varriount_ is now known as Varriount |
| 22:21:15 | * | io2 quit (Quit: ...take irc away, what are you? genius, billionaire, playboy, philanthropist) |
| 22:24:08 | Araq | flaviu1: " Brackets in backtick quotes #1217 " works as the spec/grammar says it works. we can support your idea easily though. |
| 22:25:08 | Varriount | flaviu1: I'm curious, why would you want to use brackets and braces as operators? |
| 22:25:29 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 22:46:24 | Araq | Varriount: just check his example code |
| 22:46:53 | Araq | it's cool because then you don't have to use parLe, parRi, bracketLe, bracketRi, curlyLe, curlyRi |
| 22:47:18 | flaviu1 | Varriount: Exectly |
| 22:47:30 | flaviu1 | If only I could spell... |
| 23:12:11 | * | ehaliewicz joined #nimrod |
| 23:14:10 | * | Jehan_ quit (Quit: Leaving) |
| 23:19:54 | * | flaviu1 quit (Remote host closed the connection) |
| 23:21:37 | * | flaviu1 joined #nimrod |
| 23:29:22 | * | hoverbear quit () |
| 23:36:01 | NimBot | Araq/Nimrod devel 3070264 Charlie Barto [+0 ±1 -0]: Added define check for openBSD around fmtmsg.h stuff, OpenBSD does not actually include this header |
| 23:36:01 | NimBot | Araq/Nimrod devel 295b103 Charlie Barto [+5 ±21 -0]: Merge branch 'devel' into OpenBSDFix |
| 23:36:01 | NimBot | Araq/Nimrod devel 46d4e5d Charlie Barto [+0 ±2 -0]: changed openssl to import CRYPTO_mem_set_functions from libcrypto and made sockets.nim exclude the sslv2 code on BSD |
| 23:36:01 | NimBot | Araq/Nimrod devel b9b45c1 Andreas Rumpf [+0 ±3 -0]: Merge pull request #1180 from barcharcraz/OpenBSDFix... 2 more lines |
| 23:37:45 | * | darkf joined #nimrod |
| 23:41:36 | NimBot | Araq/Nimrod devel 7754bc7 EXetoC [+0 ±1 -0]: gpp -> gcc |
| 23:41:36 | NimBot | Araq/Nimrod devel 502f7bf EXetoC [+0 ±3 -0]: Resolve type mismatches. |
| 23:41:36 | NimBot | Araq/Nimrod devel f66f43b EXetoC [+0 ±4 -0]: Fix more 'undeclared identifier' errors. |
| 23:41:36 | NimBot | Araq/Nimrod devel 444e8dd EXetoC [+0 ±1 -0]: Revert changes to koch. |
| 23:41:36 | NimBot | 1 more commits. |