00:00:21 | Soak | but to be able to use this proc I need to manually increase the position of the stream with setPosition() |
00:00:51 | Soak | I don't know is this is the best way to do that.. |
00:00:59 | Soak | if this is* |
00:02:47 | ephja | I fail at reading comprehension |
00:03:02 | ephja | isn't that unnecessary? |
00:04:34 | * | coopernurse quit (Quit: WeeChat 1.1.1) |
00:04:53 | Soak | maybe I didn't used it correctly, will make tests |
00:08:30 | * | pregressive quit (Remote host closed the connection) |
00:12:06 | * | desophos_ quit (Remote host closed the connection) |
00:12:25 | * | desophos joined #nim |
00:12:49 | ephja | it's always increased if not at the end, and you can just check if '\0' is being returned; unless, of course, you expect embedded null's |
00:13:42 | * | elrood quit (Quit: Leaving) |
00:14:52 | Soak | yeah the problem is my stream is never isNil == true |
00:15:12 | Soak | even at EOF |
00:15:48 | Soak | I think I miss-understood the example |
00:26:02 | Soak | ephja, what if I get some nulls in the middle of the binary? |
00:27:07 | Varriount_ | Soak: Keep in mind that if you're using the built-in procedures for reading and writing, there will already be a buffer in place by the underlying os/C library. |
00:28:12 | ephja | there's also atEnd |
00:28:12 | Varriount_ | Often you should simply read whatever file/stream/connection until the OS notifies you of an error, otherwise you risk race conditions. |
00:29:06 | Soak | Varriount_, in fact I need to modify each byte of a binary passed to the program, the idea was to read a byte from a file one at a time then write it immediately |
00:29:41 | Soak | because in the case of the user passing a very large binary, you need to keep it in memory if you don't use a stream |
00:29:52 | Soak | no? |
00:30:54 | Soak | anyway atEnd is perfect ephja, I should saw it, sorry |
00:32:11 | * | desophos quit (Remote host closed the connection) |
00:33:22 | * | strcmp2 joined #nim |
00:36:11 | * | strcmp1 quit (Ping timeout: 264 seconds) |
00:36:15 | * | desophos joined #nim |
01:04:50 | * | desophos quit (Remote host closed the connection) |
01:07:26 | * | desophos joined #nim |
01:09:50 | * | desophos quit (Remote host closed the connection) |
01:10:09 | * | desophos joined #nim |
01:11:43 | * | juanfra quit (Ping timeout: 246 seconds) |
01:17:45 | * | zepolen joined #nim |
01:27:42 | * | juanfra joined #nim |
01:28:32 | * | juanfra quit (Client Quit) |
01:29:31 | * | anthgur joined #nim |
01:38:05 | * | desophos quit (Remote host closed the connection) |
01:40:16 | * | juanfra joined #nim |
01:46:24 | * | pregressive joined #nim |
02:00:06 | * | jaco60 quit (Ping timeout: 246 seconds) |
02:05:00 | * | desophos joined #nim |
02:06:01 | * | desophos_ joined #nim |
02:06:16 | * | desophos quit (Disconnected by services) |
02:06:20 | * | desophos_ is now known as desophos |
02:07:27 | * | brson quit (Ping timeout: 246 seconds) |
02:21:50 | * | pregressive quit (Remote host closed the connection) |
02:40:10 | Varriount_ | reactormonk: Ping |
02:40:14 | * | Varriount_ is now known as Varriount |
02:59:13 | * | Varriount quit (Ping timeout: 265 seconds) |
03:05:28 | * | desophos_ joined #nim |
03:08:01 | * | desophos quit (Ping timeout: 252 seconds) |
03:26:38 | * | anthgur quit (Quit: My Mac has gone to sleep. ZZZzzz…) |
03:41:45 | * | ephja quit (Ping timeout: 265 seconds) |
03:46:28 | * | solidsna_ quit (Quit: My Mac has gone to sleep. ZZZzzz…) |
03:49:56 | * | desophos joined #nim |
03:50:41 | * | brson joined #nim |
03:52:27 | * | jakesyl quit (Ping timeout: 246 seconds) |
03:53:37 | * | brson quit (Client Quit) |
03:55:10 | * | desophos quit (Ping timeout: 272 seconds) |
03:58:24 | * | strcmp1 joined #nim |
03:59:43 | * | strcmp2 quit (Ping timeout: 252 seconds) |
04:05:34 | * | jakesyl joined #nim |
04:07:05 | * | zepolen quit (Remote host closed the connection) |
04:09:27 | * | Varriount joined #nim |
04:28:09 | * | onionhammer quit (Read error: Connection reset by peer) |
04:33:40 | * | desophos_ is now known as desophos |
04:53:13 | * | solidsnack joined #nim |
04:54:06 | * | darkf joined #nim |
05:13:39 | Varriount | Araq: So, there's a problem with how Nim is handling command line arguments on Windows. Apparently its possible to start a process and have the first part of the command line string not be the executable name, or even the path to the executable. |
05:14:29 | * | vendethiel joined #nim |
05:33:47 | * | zaquest quit (Ping timeout: 264 seconds) |
05:39:56 | * | vendethiel quit (Ping timeout: 276 seconds) |
05:41:10 | * | onionhammer joined #nim |
05:46:12 | * | zaquest joined #nim |
06:06:23 | * | darkf_ joined #nim |
06:08:19 | * | xyproto quit (Ping timeout: 240 seconds) |
06:08:50 | * | xyproto joined #nim |
06:08:59 | * | darkf quit (Ping timeout: 240 seconds) |
06:25:52 | * | darkf_ is now known as darkf |
06:40:30 | * | Demon_Fox quit (Ping timeout: 240 seconds) |
06:55:55 | * | zepolen joined #nim |
06:55:57 | * | Demon_Fox joined #nim |
06:58:56 | * | desophos quit (Read error: Connection reset by peer) |
07:20:32 | * | solidsnack quit (Quit: My Mac has gone to sleep. ZZZzzz…) |
07:21:26 | * | Matthias247 joined #nim |
07:24:58 | * | gour joined #nim |
07:25:55 | * | solidsnack joined #nim |
07:41:27 | * | Matthias247 quit (Read error: Connection reset by peer) |
07:43:40 | * | Kingsqueee joined #nim |
07:44:13 | * | Kingsquee quit (Ping timeout: 250 seconds) |
07:44:46 | * | nchambers is now known as dts|pokeball |
07:50:23 | * | solidsnack quit (Quit: My Mac has gone to sleep. ZZZzzz…) |
07:51:51 | * | Trustable joined #nim |
08:04:03 | * | strcmp1 quit (Remote host closed the connection) |
08:05:10 | Varriount | Araq: When retrofitting procedures with not-nil return types, what should be done if a string parameter turns out to be nil? |
08:05:26 | Varriount | Should the procedure raise an error/ |
08:05:28 | Varriount | *? |
08:09:11 | * | strcmp1 joined #nim |
08:10:45 | * | yglukhov joined #nim |
08:11:16 | Araq | Varriount: shouldn't the type checker complain instead? |
08:17:23 | Varriount | Araq: I'm turning something like 'proc join(a, b: string): string' to 'proc join(a, b: string): nnstring' |
08:17:40 | Varriount | Er, `nnstring = string not nil` |
08:18:14 | Araq | i see. |
08:19:07 | Araq | well it shouldn't raise an exception for input nils, nor should it check for nil, nil might crash, it has always been like that |
08:19:37 | Varriount | Araq: Yes, but I can't just tell the type checker that. |
08:20:23 | Varriount | If the result depends on both of the parameters being valid strings, then there must be an explicit path that deals with them. |
08:21:31 | Varriount | I figure that, at some point, Nim should probably transition towards non-nillable strings by default (and possibly towards immutable strings as well). Retrofitting standard library procedures is a good place to start, and fits nicely with some of the Nimsuggest modifications I've made. |
08:22:18 | Araq | yeah I dunno. OnO patched the compiler to make 'not nil' the default |
08:23:11 | Araq | but I don't believe in this "omg null was a morobillion dollar mistake" nonsense |
08:23:37 | Varriount | Araq: Neither do I, however for strings I think it's a suitable type characteristic. |
08:23:49 | Araq | the language gets quite some expressivity out of the axiom of choice |
08:25:56 | Varriount | Araq: And before you start complaining about immutable strings, I've done some compiler patching to log string copies vs string modifications. The preliminary work suggests that the ratio of copies to modifications is quite high. |
08:26:41 | Araq | maybe but immutability is not the only design choice we have to mitigate this problem |
08:26:56 | * | gokr joined #nim |
08:27:08 | Varriount | But it is the easiest for the programmer to make direct use of. |
08:27:20 | Araq | IMHO 'freeze' (aka 'shallow') is simply underdeveloped right now |
08:28:04 | Araq | and is easy enough to explain, where Python uses lists +string.join, Nim just uses strings + freeze |
08:28:21 | Varriount | And what about the extra checks that will need to be made? As far as I'm concerned, immutable strings are just a type-safe version of using shallow() |
08:28:22 | Araq | and gets quite some boost for string ops |
08:28:43 | Araq | there are few strategic places that need to be patched |
08:29:38 | Araq | seems way easier than ImmutableString but ofc we lose some type safety |
08:30:55 | Araq | also O(1) slicing would be nice ... *cough* |
08:30:58 | Araq | bbs |
08:31:09 | Varriount | Araq: Well, considering the immutable string type I have written up is less than 100 lines of actual code. |
08:34:34 | Varriount | Araq: The problem is that it's not always clear where and how often strings are copied. Even a simple formatting operation ("Hello $#" % [strVar]") performs about 4 of them. |
08:36:47 | Varriount | Implicit state is bad. It leads to hard to spot bugs when code is refactored (yes, even with checks). |
08:37:08 | * | Kingsqueeee joined #nim |
08:37:28 | Varriount | Araq: If you want a particularly apt example, just look at environment variables. |
08:39:34 | * | Kingsqueee quit (Ping timeout: 250 seconds) |
08:42:24 | * | sdw quit (Read error: Connection reset by peer) |
08:53:56 | Araq | Varriount: well string formating boils down to appending. and appending needs to copy the source string |
08:54:19 | Araq | you can try ropes.nim instead which uses concatenation trees instead. it |
08:54:28 | Araq | 's much slower though |
08:55:30 | Araq | maybe OnO's distinct patch really helps us: type ImmutableString {.borrowAll.} = distinct string |
08:57:28 | Araq | but *shrug*, more string types in the stdlib will hurt more than they would solve. so API 1 uses stringA, API 2 uses stringB and conversions between them usually imply a copy ... see C++. |
08:57:35 | Varriount | But that's still a copy-on-assignment data structure. |
08:58:02 | Araq | we can do COW under the hood, it's not hard, is it? |
08:58:15 | Varriount | Tell that to python, rust, and java |
08:59:22 | Araq | so where is the detailed technical analysis about why python and java choose immutability rather than COW? |
08:59:33 | Varriount | Well, copy on write requires an additional check for every basic during operation. |
08:59:41 | Varriount | *string |
09:00:02 | Araq | which is cheap. |
09:01:16 | Araq | rust's api also has its problems with strings, last time i looked at it |
09:01:27 | Varriount | But it's an entirely new branch for the processor to try and predict |
09:01:31 | Varriount | Oh? |
09:02:28 | Araq | doesn't look like a hard-to-predict branch. my gut feeling is that it is very easy to predict |
09:02:51 | Araq | ownership doesn't change from run to run inside a loop construct |
09:04:32 | Varriount | Araq: And the implicit state caused by shallow vs non-shallow string objects? |
09:04:59 | Varriount | I prefer my type errors to happen at compile time, not run time. |
09:05:17 | Araq | well you're paying that price already, right now, because shallow strings alreaddy exist |
09:05:38 | Varriount | And thankfully aren't used too often. |
09:06:21 | Araq | it's a tradeoff, it always is, between polymorphism and compile time guarantees |
09:06:57 | Araq | you prefer to see your errors at compile time, I prefer to not have 2 or 3 or 4 different string types in the language |
09:08:27 | Varriount | But what shallow is doing is exactly that. It introduces two different semantic behaviors, at run-time no less. |
09:09:02 | Araq | but at least they are very compatible with each other |
09:09:26 | Varriount | And why wouldn't mutable and immutable strings be incompatible? |
09:09:51 | Varriount | At most, converting from one to the other requires a memory copy. Possibly not even that. |
09:10:12 | Araq | proc now(s: string): string |
09:10:52 | Araq | proc future[T: string|imstring](s: T): T |
09:12:19 | Araq | proc futureb(s: varargs[string|imstring]): string |
09:12:34 | * | antoniomo joined #nim |
09:12:52 | Araq | it's really the same problem we have with 'not nil' |
09:12:56 | Varriount | Or you just create two procedures, each explicitly handling the distinct type. Templating helps too. |
09:13:24 | Araq | but if the proc only performs readonly access it doesn't care |
09:13:34 | Araq | it supports both string and imstring out of the box |
09:14:26 | Araq | it's the same problem that a 'const' type qualifier brings |
09:16:08 | Varriount | Araq: wrap the body up in a template, or use a macro to duplicate and modify the procedure. Have read operations return strings of the same type. |
09:16:28 | Araq | be my guest and try it |
09:16:36 | Varriount | That's already what's done for the various table types. |
09:16:49 | Araq | I won't because I already know the results ;-) |
09:17:46 | * | jaco60 joined #nim |
09:27:21 | reactormonk | Varriount, that's like 4 in the morning here. |
09:33:04 | * | darkf_ joined #nim |
09:36:09 | * | darkf quit (Ping timeout: 246 seconds) |
09:47:30 | * | gokr1 joined #nim |
09:48:54 | * | coffeepot joined #nim |
09:50:10 | * | Arrrr joined #nim |
09:50:15 | * | solidsnack joined #nim |
09:50:57 | * | gokr quit (Ping timeout: 255 seconds) |
09:53:26 | * | makoLine quit (Ping timeout: 276 seconds) |
09:54:26 | * | solidsnack quit (Ping timeout: 240 seconds) |
10:01:34 | * | gokr joined #nim |
10:05:02 | * | gokr1 quit (Ping timeout: 260 seconds) |
10:06:44 | * | vendethiel joined #nim |
10:25:04 | * | elrood joined #nim |
10:42:46 | * | zepolen quit (Remote host closed the connection) |
10:42:58 | * | zepolen joined #nim |
10:49:19 | * | gokr quit (Quit: Leaving.) |
11:07:46 | * | renesac quit (Read error: Connection reset by peer) |
11:20:32 | * | ibeex joined #nim |
11:35:45 | * | mindriot101 joined #nim |
11:39:03 | * | solidsnack joined #nim |
11:45:14 | * | solidsnack quit (Ping timeout: 276 seconds) |
11:47:33 | Varriount | reactormonk, Araq: https://github.com/nim-lang/nimsuggest/pull/18 |
11:51:51 | * | Demon_Fox quit (Ping timeout: 265 seconds) |
11:58:39 | * | Kingsqueeee quit (Quit: https://i.imgur.com/qicT3GK.gif) |
11:59:43 | Araq | Varriount: cant say I like it. what problem does it solve? |
12:09:10 | * | mindriot101 quit (Remote host closed the connection) |
12:10:10 | reactormonk | Varriount, btw: https://github.com/nim-lang/nimsuggest/pull/17 |
12:14:29 | * | theduke quit (Ping timeout: 276 seconds) |
12:17:35 | * | gokr joined #nim |
12:22:32 | * | zepolen quit (Remote host closed the connection) |
12:26:15 | * | theduke joined #nim |
12:37:09 | * | BitPuffin joined #nim |
12:40:43 | * | solidsnack joined #nim |
12:45:30 | * | solidsnack quit (Ping timeout: 265 seconds) |
13:09:52 | * | mindriot101 joined #nim |
13:11:40 | * | xyproto left #nim ("bye") |
13:24:32 | * | Jehan_ joined #nim |
13:33:25 | * | renesac joined #nim |
13:39:10 | * | mindriot101 quit (Remote host closed the connection) |
13:39:21 | * | ephja joined #nim |
13:39:27 | * | mindriot101 joined #nim |
13:52:57 | * | yglukhov quit (Remote host closed the connection) |
13:55:07 | * | yglukhov joined #nim |
14:08:15 | * | elrood quit (*.net *.split) |
14:08:16 | * | mnemonikk quit (*.net *.split) |
14:08:17 | * | JStoker quit (*.net *.split) |
14:08:48 | * | JStoker joined #nim |
14:09:11 | * | mindriot101 quit (Remote host closed the connection) |
14:12:39 | * | mindriot101 joined #nim |
14:15:57 | * | elrood joined #nim |
14:15:57 | * | mnemonikk joined #nim |
14:25:22 | * | askatasuna joined #nim |
14:26:49 | Varriount | reactormonk: :D |
14:28:44 | Varriount | Araq: Well, aside from the reasons I gave in the PR, the current code is a jumbled mess of compiler-specific and nimsuggest code. |
14:28:54 | * | solidsnack joined #nim |
14:29:17 | Varriount | Again, the main reason for the changes was to allow for easier addition of modes. |
14:32:55 | * | solidsnack quit (Ping timeout: 240 seconds) |
14:34:58 | Araq | Varriount: but who wants to add modes? the idea of nimsuggest is to use the compiler as a library and I already started work on nimindex which stores this information in some database |
14:35:48 | Araq | so in other words, it's extensible by just creating a different tool |
14:36:27 | Araq | which uses the compiler api |
14:36:47 | Araq | arguably the EPC mode should be its own exe too |
14:38:17 | Araq | much more important is to refactor the compiler to be free of globals so that it becomes much more useful as a library |
14:38:25 | * | ibeex quit (Quit: Textual IRC Client: www.textualapp.com) |
14:39:27 | Araq | and even if we decide to refactor the tiny nimsuggest part, we MUST NOT change the protocol. |
14:40:23 | Araq | it's not acceptable that the people who provide nimsuggest integration need to adapt their code |
14:40:54 | Araq | think about the end user please. So I use atom, do a nimsuggest update and nothing works anymore |
14:45:21 | * | coffeepot quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) |
14:47:35 | * | coffeepot joined #nim |
14:48:19 | * | Jehan_ quit (Quit: Leaving) |
14:50:04 | * | antoniomo quit (Quit: WeeChat 1.3) |
14:53:02 | * | zepolen joined #nim |
14:58:27 | * | zepolen quit (Remote host closed the connection) |
15:01:30 | * | zepolen joined #nim |
15:02:42 | * | zepolen quit (Remote host closed the connection) |
15:07:51 | * | zepolen joined #nim |
15:14:42 | * | Jehan_ joined #nim |
15:15:22 | * | zepolen quit (Remote host closed the connection) |
15:17:15 | * | pregressive joined #nim |
15:22:32 | * | yglukhov quit (Remote host closed the connection) |
15:23:05 | * | yglukhov joined #nim |
15:37:01 | * | zepolen joined #nim |
15:39:42 | * | Ven_ joined #nim |
15:41:30 | * | zepolen quit (Remote host closed the connection) |
15:43:19 | Arrrr | Compilers are databases https://youtu.be/WxyyJyB_Ssc |
15:44:50 | theduke | is there a way to print out the code generated by a template? for debugging |
15:45:20 | * | zepolen joined #nim |
15:48:48 | * | zepolen quit (Remote host closed the connection) |
15:49:32 | * | dts|pokeball is now known as nchambers |
15:50:57 | * | zepolen joined #nim |
15:55:32 | Jehan_ | theduke: Something like https://gist.github.com/rbehrends/b28a62903ad27f974eed ? |
15:56:32 | * | zepolen quit (Remote host closed the connection) |
15:58:36 | theduke | Jehan: awesome, thanks |
16:00:46 | * | Arrrr quit (Ping timeout: 265 seconds) |
16:00:59 | * | zepolen joined #nim |
16:01:21 | * | Ven_ quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
16:03:05 | * | darkf_ is now known as darkf |
16:04:48 | * | Arrrr joined #nim |
16:04:58 | * | BitPuffin quit (Read error: Connection reset by peer) |
16:06:02 | * | zepolen quit (Remote host closed the connection) |
16:09:22 | NimBot | nim-lang/Nim devel c017904 Anatoly Galiulin [+0 ±2 -0]: Fixed issue 3513: wrong setupQuery realization |
16:09:22 | NimBot | nim-lang/Nim devel 29fd3ed Dominik Picheta [+0 ±2 -0]: Merge pull request #3514 from vegansk/3513_pgsql_prepstat... 2 more lines |
16:11:15 | * | BitPuffin joined #nim |
16:16:03 | * | Ven_ joined #nim |
16:16:08 | * | zama_ joined #nim |
16:17:08 | * | lyro quit (Ping timeout: 240 seconds) |
16:17:10 | * | zama quit (Ping timeout: 240 seconds) |
16:17:13 | * | fold1 quit (Ping timeout: 240 seconds) |
16:18:19 | * | fold2 joined #nim |
16:19:00 | * | lyro joined #nim |
16:19:31 | * | Jesin quit (Quit: Leaving) |
16:21:10 | * | zepolen joined #nim |
16:23:50 | * | zepolen quit (Remote host closed the connection) |
16:26:28 | * | Jesin joined #nim |
16:38:51 | * | ibeex joined #nim |
16:38:56 | theduke | aaand one more question regarding macros/templates: is there a way to access something in the CURRENT scope from a macro? bindSym, as far as i can tell from my tests, only binds the scope of where the macro is defined, not the scope of where it is used. |
16:39:01 | * | Guest48911isaway is now known as Guest48911 |
16:39:04 | * | Guest48911 is now known as Guest48911isaway |
16:39:26 | * | ibeex quit (Client Quit) |
16:40:01 | * | ibeex joined #nim |
16:40:01 | * | ibeex quit (Client Quit) |
16:40:20 | * | vqrs quit (Ping timeout: 276 seconds) |
16:41:25 | * | Ven__ joined #nim |
16:41:41 | * | Ven_ quit (Read error: Connection reset by peer) |
16:41:55 | * | vqrs joined #nim |
16:44:02 | theduke | clarificiaton: |
16:44:03 | theduke | https://gist.github.com/theduke/6bfa46738f679f036712 |
16:45:01 | theduke | I would I would want test1() to print "customEcho", not "myEcho" |
16:46:00 | theduke | oh ok, figured it out. never mind |
16:50:20 | * | Ven__ quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
16:54:13 | * | strcmp2 joined #nim |
16:56:40 | * | Ven_ joined #nim |
16:56:52 | * | zepolen joined #nim |
16:57:48 | * | strcmp1 quit (Ping timeout: 265 seconds) |
17:01:08 | * | Ven_ quit (Client Quit) |
17:12:50 | * | zepolen quit (Ping timeout: 240 seconds) |
17:18:51 | * | coffeepot quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) |
17:25:47 | * | nande joined #nim |
17:27:06 | * | yglukhov quit (Ping timeout: 272 seconds) |
17:29:02 | * | strcmp1 joined #nim |
17:30:07 | * | zepolen joined #nim |
17:30:16 | * | mindriot101 quit (Ping timeout: 272 seconds) |
17:32:34 | * | strcmp2 quit (Ping timeout: 250 seconds) |
17:37:54 | * | pregressive quit (Remote host closed the connection) |
17:41:51 | * | pregressive joined #nim |
17:45:34 | * | dloss joined #nim |
17:46:27 | * | Gonzih joined #nim |
17:49:03 | * | dloss quit (Remote host closed the connection) |
17:49:56 | * | brson joined #nim |
17:52:34 | * | mindriot101 joined #nim |
17:56:03 | * | desophos joined #nim |
18:01:42 | * | zepolen quit (Remote host closed the connection) |
18:02:24 | * | mindriot101 quit (Remote host closed the connection) |
18:02:43 | * | mindriot101 joined #nim |
18:03:26 | * | nande quit (Read error: Connection reset by peer) |
18:08:51 | * | darkf quit (Quit: Leaving) |
18:13:57 | bbl | Araq: will future module make it to system? |
18:19:16 | * | desophos quit (Remote host closed the connection) |
18:24:53 | * | desophos joined #nim |
18:30:00 | * | euantor joined #nim |
18:41:09 | * | mindriot101 quit (Remote host closed the connection) |
18:42:27 | * | Gonzih quit (Ping timeout: 240 seconds) |
18:51:59 | * | zepolen joined #nim |
18:52:00 | * | zepolen quit (Remote host closed the connection) |
18:52:19 | * | zepolen joined #nim |
18:59:11 | * | Matthias247 joined #nim |
19:01:28 | * | zepolen quit (Remote host closed the connection) |
19:24:03 | * | mat4 joined #nim |
19:24:05 | mat4 | hello |
19:31:58 | * | mindriot101 joined #nim |
19:36:26 | * | antoniomo joined #nim |
19:44:39 | * | Gonzih joined #nim |
19:44:58 | * | Ven_ joined #nim |
19:45:35 | * | desophos quit (Remote host closed the connection) |
19:49:30 | * | Gonzih quit (Ping timeout: 240 seconds) |
19:55:33 | * | Ven_ quit (Read error: Connection reset by peer) |
19:55:39 | * | Ven__ joined #nim |
19:56:25 | * | desophos joined #nim |
19:58:28 | * | desophos quit (Remote host closed the connection) |
20:03:04 | * | euantor quit () |
20:03:08 | * | BitPuffin quit (Ping timeout: 276 seconds) |
20:06:13 | * | solidsnack joined #nim |
20:06:18 | * | solidsnack quit (Read error: Connection reset by peer) |
20:09:58 | * | Ven__ quit (Read error: Connection reset by peer) |
20:11:00 | * | desophos joined #nim |
20:12:45 | theduke | is there any way to 'catch' something like a SIGSEGV with a handler? |
20:15:03 | Arrrr | i dont think so, sigsegv i think is produced because of some unsafe code |
20:15:52 | * | Ven_ joined #nim |
20:17:00 | * | zepolen joined #nim |
20:18:15 | NimBot | nim-lang/Nim fix-parseopt2-externs 3832ea0 Varriount [+0 ±1 -0]: Prevent Exported C procedure collisions... 2 more lines |
20:18:20 | * | askatasuna quit (Quit: WeeChat 1.3) |
20:20:41 | ephja | Arrrr: I thought it was possible in D |
20:21:08 | * | gokr quit (Quit: Leaving.) |
20:21:45 | theduke | it's also possible in c |
20:22:08 | Arrrr | I don't know, then it must be possible i suppose |
20:22:15 | elrood | you can, but before you do read https://www.securecoding.cert.org/confluence/display/c/SIG30-C.+Call+only+asynchronous-safe+functions+within+signal+handlers |
20:23:23 | theduke | elrood: but can i do it directly with nim, or do i need to meddle with the c code? |
20:23:50 | * | Arrrr quit (Read error: Connection reset by peer) |
20:25:06 | * | Guest48911isaway is now known as Guest48911 |
20:25:31 | * | Ven_ quit (Read error: Connection reset by peer) |
20:25:32 | elrood | tbh, no clue. since you can't really safely do many useful things in your signal handler and catching those is of questionable value, i'd bet noone has bothered writing nim code for that case |
20:25:34 | * | desophos quit (Remote host closed the connection) |
20:26:24 | mat4 | what case was that again please ? |
20:26:25 | * | desophos joined #nim |
20:26:51 | elrood | signal handling |
20:30:10 | elrood | Araq or someone else with more experience in nim will probably prove my assumption wrong in a minute ;) |
20:34:10 | * | gokr joined #nim |
20:36:34 | mat4 | there exist for sure various strategies implementing signal handling and I think most are applicable in Nim |
20:37:24 | * | brson_ joined #nim |
20:40:06 | * | brson quit (Ping timeout: 246 seconds) |
20:47:03 | * | nah joined #nim |
20:48:57 | * | zepolen quit (Remote host closed the connection) |
20:49:34 | * | nah quit (Client Quit) |
20:50:32 | ephja | you can't catch SIGKILL that way though, can you? I wonder how they did it in D |
20:50:43 | ephja | oops, not SIGKILL |
20:51:06 | * | zepolen joined #nim |
20:52:06 | ephja | http://www.deadalnix.me/2012/03/24/get-an-exception-from-a-segfault-on-linux-x86-and-x86_64-using-some-black-magic/ |
21:00:14 | theduke | the reason i need it: i'm writing a test framework that should be able to handle tests that fail with things like nil pointer access |
21:00:48 | theduke | i tried running the test in a new process, but the SIGSEGV still kills the main process |
21:09:15 | * | gour quit (Quit: WeeChat 1.3) |
21:11:21 | mat4 | if I remember correctly that's a Un*x feature. I saw code which circumvent that behaviour though polling |
21:12:11 | desophos | theduke: what kind of testing? |
21:12:19 | desophos | just curious |
21:12:21 | desophos | is it open source? |
21:13:32 | * | gour joined #nim |
21:15:16 | theduke | desophos: yeah, it will be open source. it's a generic test framework with the option to run tests in parallel, custom result reporters for continous integration systems |
21:15:56 | theduke | you can use bdd style testing: expect(x).To(Equal(44)) / Excpect([1,2]).To(Contain(33)), ... |
21:16:12 | theduke | or also just regular assertions if you prefer |
21:16:42 | desophos | cool, do you intend for it to be a Robot alternative? |
21:16:46 | ephja | that's some rigorous testing |
21:16:53 | * | Jehan_ quit (Quit: Leaving) |
21:17:22 | ephja | is it not worth extending the unittest module? |
21:18:07 | theduke | unittest.nim is really simplistic. it's just 300 LOC |
21:18:31 | theduke | but maybe maintainers will be interested in including my stuff in the stdlib, we'll see |
21:18:41 | theduke | but i need to get things ironed out first |
21:18:55 | ephja | right |
21:23:47 | theduke | but it's probably better suited for a contrib library nust a nimble install away |
21:23:51 | desophos | theduke: are you familiar with Robot (test framework in Python) |
21:23:53 | desophos | ? |
21:23:57 | theduke | desophos: no |
21:24:13 | desophos | theduke: http://robotframework.org/ |
21:24:53 | desophos | might be interesting/helpful |
21:25:02 | theduke | desophos: i will check it out, thanks |
21:25:10 | desophos | it's what we use at my workplace |
21:27:10 | desophos | theduke: i'd be interested in seeing your progress; is the source online yet? |
21:27:20 | desophos | if not, i'd appreciate a ping when you upload it :) |
21:27:42 | * | mindriot101 quit (Remote host closed the connection) |
21:29:04 | theduke | desophos: will do. i guess it'll be on github this weekend. For now i need to figure out the signal handler ;) |
21:29:42 | theduke | btw, if anyone is interested: i also wrote a playground like play.golang.org for nim |
21:30:16 | theduke | you get a website where you can just enter your code, it gets compiled and run and you see the results or errors |
21:30:25 | theduke | it's awesome for testing small things |
21:31:13 | theduke | i'll publish the nimble package in a few days |
21:32:07 | desophos | that's cool |
21:32:23 | desophos | useful especially with the lack of a repl |
21:32:38 | * | Ven_ joined #nim |
21:33:40 | theduke | you even get a history of the code you tried, saved in browsers localstorage |
21:33:59 | theduke | i'll probably add the feature to save code snippets |
21:34:28 | theduke | also writing an ORM. much to do :D |
21:36:49 | * | brson_ quit (Quit: leaving) |
21:36:56 | * | brson joined #nim |
21:38:09 | desophos | wow, nice |
21:38:57 | theduke | desophos: but the way the testing framework will function: if you run the test command, it will find all *_test.nim files under the current directory, combine them to one file, compile it and run all tests and you get pretty test info in the terminal |
21:40:16 | theduke | and the _test files will be rewritten to include the file without _test so you can test internal methods too |
21:41:10 | theduke | so if you have a file myprogram.nim and myprogram_test.nim with your tests, myprogram_test.nim will be rewritten to include myprogram.nim, compiled, all tests run |
21:41:51 | theduke | i plan to add test coverage reports too, so you can see how much and which lines of your code are tested |
21:41:57 | * | strcmp1 quit (Quit: bbs) |
21:42:08 | * | strcmp1 joined #nim |
21:42:43 | * | Ven_ quit (Ping timeout: 250 seconds) |
21:49:43 | * | antoniomo quit (Quit: WeeChat 1.3) |
21:50:27 | desophos | theduke: what's the playground site? |
21:51:42 | theduke | desophos: well, i won't host it publicly. since you would have to forbid access to many modules/ procs. everything that accesses files, works with threads, etc. but once i publish it you can just do |
21:51:50 | theduke | nimble install playground |
21:51:58 | theduke | playground |
21:51:58 | desophos | ah, okay |
21:52:14 | theduke | and it will run the server on localhost:5000 |
21:53:14 | * | gour quit (Quit: WeeChat 1.3) |
21:54:34 | * | mat4 quit (Quit: leaving) |
21:54:37 | desophos | cool. sounds like you're working on some good stuff |
21:58:26 | * | desophos quit (Remote host closed the connection) |
22:02:45 | * | desophos joined #nim |
22:06:19 | * | gokr quit (Ping timeout: 240 seconds) |
22:06:44 | * | desophos quit (Remote host closed the connection) |
22:07:15 | * | gokr joined #nim |
22:15:21 | * | Trustable quit (Quit: Leaving) |
22:17:06 | * | theduke quit (Quit: Leaving) |
22:17:27 | * | gokr quit (Quit: Leaving.) |
22:18:44 | * | yglukhov joined #nim |
22:23:20 | * | vendethiel quit (Ping timeout: 246 seconds) |
22:25:45 | * | strcmp2 joined #nim |
22:28:55 | * | jakesyl quit (Ping timeout: 240 seconds) |
22:29:17 | * | strcmp1 quit (Ping timeout: 246 seconds) |
22:31:44 | * | Guest48911 is now known as Guest48911isaway |
22:32:02 | Araq | theduke: ... oh you're away. well I've got good news and bad news. Bad news is that right now it's pretty much impossibe to catch nil deref errors at runtime. you can hack system/excpt.nim but it's really a bad solution. the good news is that yglukhov convinced me that making 'not nil' the default is not infeasible and we should do it and I convinced yglukhov that it is infeasible to do but... |
22:32:04 | Araq | ...producing a proper runtime check is ~10 lines in the compiler |
22:33:22 | Araq | so ... not sure who will win this battle but with 0.13.0 out your problem will be solved one way or the other. |
22:35:57 | * | solidsnack joined #nim |
22:37:39 | * | elrood quit (Quit: Leaving) |
22:37:47 | NimBot | nim-lang/Nim devel 3832ea0 Varriount [+0 ±1 -0]: Prevent Exported C procedure collisions... 2 more lines |
22:37:47 | NimBot | nim-lang/Nim devel ebc3438 Andreas Rumpf [+0 ±1 -0]: Merge pull request #3533 from nim-lang/fix-parseopt2-externs... 2 more lines |
22:41:09 | * | pregressive quit (Remote host closed the connection) |
22:55:22 | * | Grumpy joined #nim |
22:57:08 | * | Soak quit (Ping timeout: 250 seconds) |
22:59:43 | * | desophos joined #nim |
23:08:59 | * | makoLine joined #nim |
23:12:51 | * | strcmp2 quit (Ping timeout: 240 seconds) |
23:18:33 | * | anthgur joined #nim |
23:20:03 | * | anthgur quit (Client Quit) |
23:22:36 | * | Demon_Fox joined #nim |
23:29:27 | Araq | Varriount: will say this on the forum too, but yet another solution for nim's strings is to make assignment have reference semantics unless for string literals which need to be copied for sanity |
23:29:55 | Araq | so var x = ""; <loop that appends to x> continues to work, string assignments are fast |
23:30:25 | Araq | and there is no need for 'shallow/freeze' at all |
23:30:57 | Araq | the cost is that the language is inconsistent in its treatment of basic types but it seems like nobody really cares about this property |
23:31:27 | Araq | people are generally more concerned with speed for systems programming, so maybe that is a good solution |
23:42:34 | * | Ven_ joined #nim |
23:43:11 | * | yglukhov quit (Remote host closed the connection) |
23:49:58 | * | Ven_ quit (Ping timeout: 276 seconds) |
23:57:13 | * | Grumpy quit (Quit: Leaving) |