00:01:11 | def- | hm, something is wrong with the compiler's nimcache. Doesn't invalidate correctly sometimes, but can't reproduce |
00:02:00 | Araq | def-: can only happen for .compile files |
00:02:12 | dtscode | fowlmouth, there is no function though |
00:02:15 | fowlmouth | try --forcerebuild |
00:02:28 | def- | fowlmouth: yeah, i can just remove the nimcache directory, but it's strange |
00:04:07 | fowlmouth | dtscode, try putting it on loop() and run() |
00:04:44 | dtscode | ok |
00:05:12 | dom96 | You really shouldn't be using asyncio. |
00:05:19 | fowlmouth | dtscode, actually it should be on the handleRead function |
00:05:29 | dtscode | ok |
00:05:45 | dtscode | dom96, im trying to get it to compile before i start cleaning it up |
00:05:55 | dtscode | i still havent ruled out starting from scratch |
00:06:32 | * | brson quit (Ping timeout: 244 seconds) |
00:07:11 | fowlmouth | dtscode, proc handleRead(serv: PServer): (proc(s: PAsyncSocket){.closure, gcsafe.}) = |
00:07:26 | flaviu | https://github.com/Araq/Nim/pull/1975 |
00:07:35 | * | brson joined #nim |
00:07:38 | dtscode | yeah |
00:08:51 | Araq | flaviu: nice!!! |
00:09:01 | fowlmouth | cool flaviu that was quick too |
00:09:27 | EXetoC | weee |
00:10:28 | flaviu | unittest is a macro, and I'm pretty familiar with macros. |
00:11:51 | fowlmouth | oh i thought this was a compiler patch |
00:12:16 | fowlmouth | <_< |
00:13:34 | dom96 | dtscode: I'd say rewrite is a good idea. |
00:15:30 | dtscode | is there a basic ircd out there that i can use for reference? |
00:15:43 | flaviu | dtscode: nice import formatting :P |
00:16:00 | dtscode | flaviu, not my code :} |
00:17:15 | fowlmouth | of "MODE": if false: nil -- i wonder what the point of this was lol |
00:17:45 | def- | fowlmouth: workaround for not knowing "discard"? |
00:19:09 | fowlmouth | theres a discard right below it though >_> |
00:21:18 | dtscode | dom96, would i just need asyncnet or asyncdispatch as well? |
00:22:46 | EXetoC | so there are no major issues related to implementing the async stuff in userland? |
00:23:08 | * | irrequietus quit () |
00:25:25 | * | rpag quit (Quit: Leaving) |
00:30:14 | * | BitPuffin quit (Ping timeout: 245 seconds) |
00:45:44 | * | gmpreussner_ joined #nim |
00:45:48 | * | gmpreussner quit (Ping timeout: 244 seconds) |
00:51:30 | * | sillesta quit (Read error: Connection reset by peer) |
01:04:47 | * | sampwing quit (Ping timeout: 252 seconds) |
01:14:59 | * | Sergio96_ joined #nim |
01:17:47 | * | [dee] quit (Read error: Connection reset by peer) |
01:19:52 | akiradeveloper | What is the convention to express failure? Does Nim have a type option<T> like in some other langs? |
01:19:54 | * | gmpreussner_ quit (Ping timeout: 244 seconds) |
01:20:13 | * | gmpreussner_ joined #nim |
01:22:01 | EXetoC | what about exceptions? |
01:24:25 | * | Trustable quit (Quit: Leaving) |
01:27:27 | * | brson quit (Quit: leaving) |
01:33:02 | akiradeveloper | exception is slow |
01:34:04 | akiradeveloper | exception is usually used as expressing failure in Nim? |
01:34:28 | EXetoC | is it? |
01:35:18 | def- | Depends on the situation |
01:35:25 | def- | for exceptional errors exceptions are used |
01:35:34 | akiradeveloper | In some language like OCaml, exception is apparently slower than returning error |
01:35:36 | def- | otherwise invalid values like -1 or nil |
01:35:39 | * | sillesta joined #nim |
01:35:44 | akiradeveloper | ok. -1 or nil |
01:36:03 | def- | you can define your own option<T> type if you want to write your code in that style |
01:36:38 | akiradeveloper | but Nim doesn't have pattern matching so that style doesn't fit I think |
01:37:32 | akiradeveloper | no convention to return (error, obj) pair like golang? |
01:38:32 | def- | no, haven't seen that |
01:39:53 | akiradeveloper | ok thanks. |
01:41:12 | akiradeveloper | is there no path class? |
01:42:25 | def- | Path stuff is in the OS module: http://nim-lang.org/os.html |
01:43:04 | ldlework | you can return a tuple |
01:43:33 | akiradeveloper | def-: thanks. we don't wrap string in a path type |
01:43:36 | ldlework | I guess that's not the same :) |
01:44:38 | akiradeveloper | Nim has a convention in error handling similar to C (linux kernel etc.) |
01:45:18 | def- | akiradeveloper: with the advantage that you can't just implicitly throw the error away, you have to actually handle it or explicitly discard it |
01:47:33 | fowlmouth | akiradeveloper, you can return a tuple and unpack it to use it like go's tuples |
01:48:29 | ldlework | fowlmouth: oh okay so I'm not crazy |
01:48:52 | akiradeveloper | various kind of advances thanks but I am confused |
01:49:03 | ldlework | fowlmouth: you'd have to return a ref type as the error right? |
01:49:13 | ldlework | so you could optionally return nil? |
01:51:55 | fowlmouth | ldlework, string can be nil |
01:52:00 | fowlmouth | is nil by default |
01:53:17 | ldlework | akiradeveloper: make sense? |
01:59:16 | EXetoC | Option[T] and a converter maybe |
02:01:16 | EXetoC | fowlmouth: right, your TMaybe has a converter |
02:04:23 | fowlmouth | option[t] is different |
02:04:42 | akiradeveloper | Idlework: I am confused yet |
02:04:45 | fowlmouth | go's convention is more like either[string, T] |
02:04:54 | akiradeveloper | TMaybe? |
02:04:56 | flaviu | I wrote https://github.com/flaviut/optional_t and think it's awesome, but I'd like criticism. |
02:05:20 | EXetoC | fowlmouth: ok.. is that not unconventional? |
02:05:46 | fowlmouth | EXetoC, is what unconventional? |
02:06:43 | EXetoC | fowlmouth: go's 'option' |
02:06:58 | fowlmouth | its not the same thing |
02:07:24 | fowlmouth | option<t> means t or nothing, go's is an error string or a value |
02:07:49 | EXetoC | that's what I mean by unconventional. oh well |
02:07:50 | flaviu | EXetoC: fowl is talking about Either[T, string], which is a superset of Option[T] (Option[T] == Either[T, Unit]) |
02:08:04 | EXetoC | I got that |
02:08:27 | flaviu | Either is not unconventional, it's very common in functional programming. |
02:08:29 | flaviu | http://www.scala-lang.org/api/current/index.html#scala.util.Either |
02:08:54 | fowlmouth | but its not really clear what the error string actually is |
02:08:59 | EXetoC | but he's saying that it's like 'either', even though it's called 'optional', right? |
02:09:32 | fowlmouth | is it some kind of error code that can be prepared so a good message can be output to the user or is it a message that is OK to be shown to the user |
02:10:17 | flaviu | EXetoC: It's a convention more than a concrete type. It returns `value, error`, and I assume if error exists, then value is null. |
02:11:59 | * | keyle joined #nim |
02:12:05 | EXetoC | I don't know why I thought TMaybe was inconvenient, but the interface has grown, so I'll make sure to try it though |
02:12:14 | keyle | hi |
02:12:21 | EXetoC | let's turn it into its own package and mention it on the forum, because it's neat |
02:13:10 | fowlmouth | EXetoC, i had a cool idea to optimize it but its not working |
02:16:22 | * | yonson joined #nim |
02:16:34 | * | 7YUAAFJOH quit (Read error: Connection reset by peer) |
02:16:34 | * | Etheco quit (Read error: Connection reset by peer) |
02:17:27 | fowlmouth | https://gist.github.com/fowlmouth/e5492771933e90835c51 |
02:18:11 | * | JinShil quit (Quit: Konversation terminated!) |
02:19:14 | * | JinShil joined #nim |
02:20:06 | * | sillesta quit (Remote host closed the connection) |
02:20:09 | EXetoC | that's what's not working? |
02:22:05 | fowlmouth | yea the `when` branch in the type is always true |
02:23:04 | EXetoC | use 'compile' for now? let's see what statement to use |
02:23:36 | EXetoC | *compiles |
02:25:29 | * | jefus_ joined #nim |
02:26:31 | EXetoC | compiles((let x: T; T.isNil == true)) ? |
02:27:13 | flaviu | https://gist.github.com/038804143b26ddf6fafa also doesn't work |
02:27:15 | fowlmouth | yes please try to make that work :) |
02:28:12 | flaviu | Are the when statements executed upon expansion, or once at the beginning? |
02:28:24 | flaviu | My logging says both :/ |
02:28:29 | renesac | ugh, I'm in the skyfex branch and I still get: Error: type mismatch: got (int literal(0), uint32) |
02:28:33 | renesac | :/ |
02:28:33 | flaviu | Tfalse; ref inttrue; ref inttrue |
02:29:08 | * | jefus quit (Ping timeout: 245 seconds) |
02:32:32 | renesac | and trying to correct I get "Error: ambiguous call; both system.xor(x: int64, y: int64): int64 and unsigned.xor(x: int64, y: uint64): int64 match for: (int64, int)" |
02:32:48 | renesac | not quite the same old $ error, but close |
02:35:15 | * | sampwing joined #nim |
02:41:35 | * | sampwing quit (Ping timeout: 252 seconds) |
02:42:03 | renesac | [20:56] <Araq> 5 already has the type 'int literal(5)' and is compatible with uint8, 300 is not |
02:43:22 | ldlework | renesac: I think it only works for literals |
02:43:24 | renesac | <-- acording to my experience, even now on skyfex branch, that 'int literal(5)' isn't compatible with uint8 |
02:43:47 | renesac | unsigned.<(x: T, y: T): bool |
02:43:49 | renesac | ops |
02:43:51 | * | Sergio96_ quit (Ping timeout: 264 seconds) |
02:44:08 | renesac | err, one line don't want to get printed on irc |
02:44:10 | ldlework | renesac: oh its ambiguous in that there are two functions named exactly the same |
02:44:15 | ldlework | with the same signature |
02:44:20 | ldlework | so you have to fully qualify? |
02:44:27 | ldlework | system.xor or unsigned.xor |
02:44:35 | renesac | ./tmp/aporia/a5.nim(4, 6) Error: type mismatch: got (int literal(5), uint8) |
02:44:38 | renesac | forgot about the / |
02:44:56 | renesac | but expected one of: system.<(x: TEnum, y: TEnum): bool system.<(x: string, y: string): bool |
02:45:01 | renesac | etc |
02:45:15 | renesac | ldlework: that is overload |
02:45:23 | ldlework | hmm? |
02:45:38 | renesac | the comparison operator is overloaded for all types |
02:45:47 | renesac | well, all that makes sense |
02:45:47 | ldlework | I was talking about xor above |
02:46:00 | renesac | so? |
02:46:08 | renesac | they have different types for their arguments |
02:46:28 | ldlework | oh I didn't notice |
02:46:35 | ldlework | they read the same to me, sorry |
02:46:36 | renesac | uint64 != int |
02:47:43 | renesac | if the compiler did what araq said it should be doing, I would be happy now |
02:55:05 | Varriount | blorg blorg |
02:58:07 | * | Demos joined #nim |
02:58:35 | * | sillesta joined #nim |
03:04:52 | akiradeveloper | How can I get the internal point of array or seq? |
03:05:04 | def- | what's an "internal point"? |
03:05:13 | sillesta | +er? |
03:05:21 | akiradeveloper | pointer |
03:05:27 | flaviu | akiradeveloper: addr mySeq[0] |
03:05:29 | def- | addr mySeq[0] |
03:06:01 | flaviu | haha, exactly the same code at the same time |
03:07:33 | * | reactormonk joined #nim |
03:08:12 | sillesta | are there any games that have been made with nim? |
03:08:13 | akiradeveloper | let a = @[1,2,3] echo addr(a[0]) |
03:08:19 | sillesta | all i've found are a few game libs |
03:08:26 | akiradeveloper | Error: expression has no address |
03:09:02 | fowlmouth | akiradeveloper, you wont get the address because you said you want it to be immutable when you used let, so declare it VARiable instead |
03:10:34 | * | kapil__ joined #nim |
03:10:37 | akiradeveloper | var a = @[1,2,3] echo addr(a[0]) Error: type mismatch |
03:11:06 | def- | yes, `$` is not specified for addr |
03:11:09 | EXetoC | cast to uint |
03:11:17 | fowlmouth | use repr() to get a nice string for a pointer |
03:11:21 | EXetoC | def-: ptr, but yeah |
03:11:27 | def- | oops |
03:11:28 | EXetoC | or pointer or ref |
03:11:55 | EXetoC | I actually meant what fowl said |
03:12:05 | def- | .eval var a = @[1,2,3]; echo repr(addr a[0]) |
03:12:08 | Mimbus | def-: ref 0x7f32bfa48060 --> 1 |
03:12:18 | akiradeveloper | Great |
03:12:19 | EXetoC | later. code well |
03:12:22 | akiradeveloper | it works |
03:12:32 | akiradeveloper | thanks guys |
03:17:25 | * | ARCADIVS joined #nim |
03:20:56 | * | sillesta quit (Read error: Connection reset by peer) |
03:21:12 | * | darkf joined #nim |
03:21:26 | akiradeveloper | do you guys think string can be equivalent to a void *buffer in C? I am looking for a data structure that is best fit for buffer in fuse protocol |
03:21:56 | def- | akiradeveloper: make a fixed size array? |
03:22:13 | akiradeveloper | or sequence of u8? |
03:22:33 | def- | if you need variable sized buffers, yes |
03:22:41 | akiradeveloper | yes. it is fixed size that's determined at initializing (or mouting) |
03:23:04 | akiradeveloper | array[size, u8] or string is my choice? |
03:23:11 | def- | for Nim's arrays it would have to be known at compiletime |
03:23:46 | fowlmouth | akiradeveloper, youre wrapping fuse?? |
03:24:00 | fowlmouth | just use cstring btw -- its char* |
03:24:45 | akiradeveloper | not just wrapping fuse. I am implementing nim-fuse |
03:24:54 | akiradeveloper | which is a nim binding for fuse |
03:25:03 | def- | nice |
03:25:17 | fowlmouth | cool i was thinking about doing that the other day |
03:25:53 | akiradeveloper | Just started but it is only but a Nim issue (I am Nim newbie) I completely understand fuse protocol |
03:26:38 | fowlmouth | akiradeveloper, do you need to index into the data buffer? if yes use cstring (it is char*) if no use pointer |
03:26:41 | akiradeveloper | I think I should start from buffer class defined to hide the internal structure |
03:27:41 | akiradeveloper | yes. indexing (read) and store (like memcpy) |
03:28:48 | akiradeveloper | ok I see. thanks |
03:28:52 | EXetoC | a binding is a direct interface |
03:33:59 | * | EXetoC quit (Ping timeout: 245 seconds) |
03:36:02 | akiradeveloper | I need to use libc read. Do I have to make a binding by FFI? or is there some binding module? |
03:41:39 | reactormonk | akiradeveloper, importc |
03:42:11 | reactormonk | akiradeveloper, ssize_t read(int fildes, void *buf, size_t nbyte); <- this one? |
03:42:29 | akiradeveloper | yes |
03:42:47 | reactormonk | http://nim-lang.org/posix.html <- you want this module |
03:43:27 | reactormonk | or not |
03:43:58 | reactormonk | not sure if you have ssize_t already, otherwise import it via type ssize_t {.importc: "ssize_t" } |
03:44:17 | def- | Why not just something around here?: http://nim-lang.org/system.html#readBuffer,File,pointer,int |
03:44:49 | reactormonk | for the proc: proc read(fildes: TFile, buffer: array[ ... ], nbyte: int): ssize_T {.importc: "read".} |
03:45:10 | reactormonk | point for def-. |
03:45:58 | akiradeveloper | I have a file descriptor. I need to communicate with it. TFile is too abstract |
03:46:32 | akiradeveloper | It looks what's in posix module should work |
04:05:34 | * | nimnoob joined #nim |
04:05:45 | * | VinceAddons quit (Read error: Connection reset by peer) |
04:23:08 | * | nimnoob quit (Remote host closed the connection) |
04:24:49 | def- | Araq: Hm, I'm having trouble with tcc-repl again. When I have two lines "var x = 1" and "echo x", how do I get x to be of the right type in the second one? |
04:58:57 | reactormonk | akiradeveloper, huh? Which special requirements do you have? |
05:04:20 | * | Demon_Fox joined #nim |
05:08:10 | * | brson joined #nim |
05:11:46 | * | dyu joined #nim |
05:21:36 | * | kapil__ quit (Quit: Connection closed for inactivity) |
05:40:44 | gmpreussner_ | ugh... so much hate for unsigned :) |
05:45:43 | * | Demos quit (Read error: Connection reset by peer) |
05:52:36 | reactormonk | gmpreussner_, sure, unsigned is evil >:) |
05:53:00 | gmpreussner_ | i agree, but it's a pain in the neck when wrapping C libraries |
05:53:16 | gmpreussner_ | i wonder if i should eliminate unsigned types in the wrapper as well |
05:53:46 | gmpreussner_ | reactormonk: what is the general consent on this? do people wrap everything as signed? |
06:11:21 | * | akiradeveloper_ joined #nim |
06:12:29 | akiradeveloper_ | When a program is terminated, a object in the heap are called its destructor? |
06:13:27 | akiradeveloper_ | I want to free file descriptor (OS resource) when user kill the program. How can I do this? |
06:17:19 | * | gmpreussner__ joined #nim |
06:17:30 | * | gmpreussner_ quit (Ping timeout: 244 seconds) |
06:19:28 | * | johnsoft quit (Ping timeout: 255 seconds) |
06:20:16 | * | johnsoft joined #nim |
06:30:10 | reactormonk | gmpreussner__, just don't use unsigned numbers except you get them passed |
06:30:30 | reactormonk | akiradeveloper_, IIRC destructors are a flimsy business |
06:31:48 | * | akiradeveloper left #nim (#nim) |
06:33:16 | * | dyu quit (Remote host closed the connection) |
06:49:46 | * | gmpreussner___ joined #nim |
06:50:34 | * | gmpreussner__ quit (Ping timeout: 244 seconds) |
06:52:23 | Triplefox | looking for a good way to do this(any alternative welcome) https://gist.github.com/triplefox/59a54a1697ebca769cbf |
06:55:46 | * | zahary joined #nim |
07:07:40 | * | kapil__ joined #nim |
07:08:03 | * | gour joined #nim |
07:08:17 | * | gour left #nim (#nim) |
07:21:53 | * | BlaXpirit joined #nim |
07:53:05 | * | gmpreussner___ quit (Ping timeout: 244 seconds) |
07:53:11 | * | gmpreussner___ joined #nim |
07:53:29 | * | nande quit (Remote host closed the connection) |
08:04:23 | * | brson quit (Quit: leaving) |
08:10:51 | * | BlaXpirit_ joined #nim |
08:11:03 | BlaXpirit_ | so i was porting docopt to nim |
08:11:08 | BlaXpirit_ | left_ = left[:pos] + left[pos + 1:] |
08:11:20 | BlaXpirit_ | translated to: var left2 = left[0 .. <pos] & left[pos+1 .. left.high] |
08:11:47 | BlaXpirit_ | took me somewhere between 1 and 2 hours to find the bug caused by this line |
08:20:10 | Triplefox | what is the bug |
08:21:41 | Triplefox | is it because pos + 1 can go past left.high? |
08:25:34 | BlaXpirit_ | that same problem i recently described |
08:25:53 | BlaXpirit_ | pos == 0, then left[0 .. <pos] == left |
08:26:17 | BlaXpirit_ | can't believe i fell for it the very same day! |
08:31:33 | Triplefox | ah, right |
08:34:06 | Triplefox | yeah, hmm...i couldn't see it, you couldn't see it either... |
08:36:03 | * | Varriount quit (Ping timeout: 264 seconds) |
08:36:51 | Triplefox | with substr it's not an issue though, right |
08:37:11 | BlaXpirit_ | if you remember to use the actual substr function instead of slice |
08:39:20 | Triplefox | yeah, we established before that slice was okay if you were only using the original length... |
08:48:20 | BlaXpirit_ | finally wrote an issue about this https://github.com/Araq/Nim/issues/1979 |
08:49:42 | * | gmpreussner joined #nim |
08:50:15 | * | BlaXpirit_ quit (Quit: Quit Konversation) |
08:50:26 | * | gmpreussner___ quit (Ping timeout: 244 seconds) |
08:56:07 | * | gmpreussner quit (Ping timeout: 244 seconds) |
08:56:07 | * | gmpreussner_ joined #nim |
09:03:33 | * | rkj-b joined #nim |
09:05:12 | rkj-b | Good morning |
09:05:19 | BlaXpirit | hi |
09:08:47 | rkj-b | I learned Pascal in school, read a book on C, have dabbled in 2nd order logic. Really lost in the woods! Maybe I could do a journal about how a n00b learns Nim on my blog? |
09:10:00 | BlaXpirit | maybe |
09:17:05 | * | UberLambda joined #nim |
09:21:28 | rkj-b | First I will have to clean up yhr mess in my computer. I started trying to install OCaml, but it seems like thr French own it. No pointers either, and awful multiprocessor workaround attempts. Rust looks very steep -- maybe not worth the climb. Is Nim not insanely hard to learn? I am also looking at Kitten, but the "Concatenative channel is desolate! |
09:35:59 | * | dtscode quit (Quit: ZNC - http://znc.in) |
09:40:00 | * | dtscode joined #nim |
09:40:17 | Demon_Fox | If you want easy, you can give python a go |
09:40:24 | Demon_Fox | nim is similar |
09:40:34 | Demon_Fox | but typed, and faster |
09:41:47 | * | dtscode quit (Client Quit) |
09:42:04 | * | dtscode joined #nim |
09:43:22 | Demon_Fox | So you are aware, the garbage collector in python is crap. |
09:45:18 | UberLambda | And it hinders real multithreading |
09:47:57 | Demon_Fox | That to |
09:49:36 | Demon_Fox | but concept wise, it might be useful |
09:50:22 | * | gmpreussner_ quit (Ping timeout: 244 seconds) |
09:50:33 | * | gmpreussner_ joined #nim |
09:50:41 | * | ARCADIVS quit (Quit: ARCADIVS) |
09:52:02 | rkj-b | Funny thing about "untyped" languages: when people try to create typed versions, they get pretty far, and then it all goes south. I believe interpreters and virtual machines (a la Java) are on the way out. The criminal hackers are getting so much better, and the interpreters have to be patched like Windows, and still will get owned. Pointers might be needed some time. And maybe some... |
09:52:04 | rkj-b | ...functional programming would speed up some chores (if it's robust enough). I wonder about concatenated languages like Factor and the new Kitten (which is typed). They look elegant. |
09:53:49 | vegai | Factor is quite dynamically typed too |
09:54:07 | vegai | haven't heard of Kitten before though |
09:54:44 | Demon_Fox | rkj-b, python is more of a scripting language with programming features attached |
09:56:40 | dtscode | how do you do dictionaries in nim again? |
09:58:54 | BlaXpirit | tables? |
09:58:57 | BlaXpirit | dtscode, |
10:00:29 | dtscode | uhhh maybe |
10:00:36 | dtscode | its the python equivalent to {} |
10:07:16 | rkj-b | Regarding the Kitten language, see: ( http://kittenlang.org/ ) and ( http://evincarofautumn.blogspot.com/2013/07/static-typing-in-concatenative-language.html ). This is my first encounter with IRC. (I retired from electronics, analog computers with Op-Amps even.) |
10:08:35 | dtscode | omfg theres a kitten language? |
10:09:31 | Demon_Fox | Yeah :{ |
10:09:48 | dtscode | zomg |
10:11:16 | BlaXpirit | and doge language |
10:11:42 | BlaXpirit | more than one, it seems |
10:12:14 | dtscode | i knew about that one |
10:12:28 | Demon_Fox | (ツ) |
10:12:58 | dtscode | ¯(°_o)/¯ |
10:14:44 | Demon_Fox | ¯\_(ツ)_/¯ |
10:15:05 | dtscode | (╯°Д°)╯︵ /(.□ . \) |
10:16:41 | Demon_Fox | |
10:17:19 | dtscode | ಠ_ಠ |
10:17:44 | UberLambda | http://en.wikipedia.org/wiki/LOLCODE |
10:18:04 | BlaXpirit | "GRINNING CAT FACE WITH SMILING EYES" is pretty specific |
10:18:05 | dtscode | lolscript is better |
10:18:32 | UberLambda | Lol |
10:18:33 | Demon_Fox | |
10:20:59 | * | gsingh93 quit (Quit: Connection closed for inactivity) |
10:21:54 | rkj-b | I heard that Nim can maybe 10 times faster to learn than Rust. The developer of NEW Kitten calls a lot of this "artificial expertise." I want maximum "essential" expertise. Does Nim provide that? |
10:23:09 | skyfex | What is artificial/essential expertise? |
10:25:11 | BlaXpirit | rkj-b, nim has best parts of different languages |
10:25:22 | BlaXpirit | it is a serious language |
10:25:25 | skyfex | I would say Nim is easier to get into, especially if you have experience with the languages it's inspired by - Python, Pascal, C ... And you don't need to learn the crazy memory management in Rust (which might be intuitive if you've used smart pointers etc. in C++). But there's still things in Nim that are quite hard - in particular the macro system and maybe the experimental |
10:25:25 | skyfex | typeclasses (those are buggy too) |
10:25:53 | BlaXpirit | you say macros are hard, but other languages don't even have anything like that |
10:26:02 | BlaXpirit | so you could say you don't need to learn them at all |
10:26:07 | skyfex | True |
10:27:03 | UberLambda | How can I tell the nim compiler where to output the nimcache folder and the executables? |
10:27:06 | skyfex | That should be stressed - you don't need to learn them, but they're very powefuly if you do |
10:27:08 | BlaXpirit | and I have a 1-line macro for a quick dirty thing to avoid code repetition parse_stmt("method class(self: $1): string = \"$1\"" % $typ) |
10:27:49 | BlaXpirit | yes, "method class" xDS |
10:27:50 | rkj-b | Artificial expertise = You make up a game, say baseball, or legal codes, and play by "artificial " (made up) rules. Essential expertise = You learn natural laws, say of chemistry, and then build stuff based on those realities. |
10:28:20 | BlaXpirit | rkj-b, nim tries to be useful, not pure |
10:28:55 | * | novist quit (Ping timeout: 244 seconds) |
10:28:58 | BlaXpirit | it is a pretty normal language, if you don't consider how awesome it is |
10:29:22 | rkj-b | Sounds like some of my former girlfriends. I miss them so. |
10:29:53 | * | novist joined #nim |
10:30:58 | skyfex | rkj-b: I find that distinction a bit funny in programming languages, it's all abstractions on abstractions on abstractions.. and the rules are made up all along the way down to the hardware ;) |
10:31:30 | skyfex | Although I guess you could argue that certain algorithms are "essential" |
10:35:32 | Demon_Fox | nim is like French compared Latin if you were to compare it to C. |
10:38:09 | skyfex | I guess many programmers consider the common hardware architecture (von neumann or harvard style, RISC, register based) the "natural" laws.. and abstracting upon that (Garbage Collection etc) is making up artificial rules.. but as a hardware engineer I see the hardware as artificial rules too. There are others.. they're just not popular |
10:38:30 | rkj-b | I want the language to be more like math; less like a chess game. |
10:38:50 | BlaXpirit | that's, like, pure functional programming |
10:39:04 | BlaXpirit | if you bring up math |
10:39:13 | skyfex | Ah, ok, then I misunderstood what was considered natural |
10:39:13 | BlaXpirit | i think your analogy is just not good |
10:39:18 | skyfex | So you want Haskell :P |
10:40:09 | Demon_Fox | I know that perl is modeled after language itself |
10:40:18 | * | VinceAddons joined #nim |
10:40:20 | BlaXpirit | wat |
10:40:22 | Demon_Fox | A linguist designed much of it |
10:40:35 | BlaXpirit | but you can't even read perl, what are u talking about |
10:40:51 | Demon_Fox | Well, think of it like a different language entirely |
10:41:09 | BlaXpirit | a cipher? |
10:41:16 | Demon_Fox | THink of it like: |
10:41:25 | Demon_Fox | If you only knew English and tried to learn Japanese |
10:41:42 | BlaXpirit | no, but it's something even natives can't read |
10:41:45 | Demon_Fox | You think Japanese is weird and unreadable |
10:41:45 | BlaXpirit | this is offtopic anyway |
10:41:53 | Demon_Fox | I know, my bad |
10:42:09 | skyfex | I think Nim is quite "mathy" for a imperative language.. both in terminology (using the name "procedures" instead of "functions") and in implementation (not allowing operations that discard information) |
10:43:33 | skyfex | But it doesn't define integers down to their root definition, so it's not that "hardcore" |
10:45:19 | rkj-b | I studied linguistics in school, and then as an amateur for ten years. My conclusion is it has nothing whatsoever to do with either math nor programming. I don't want a computer language to be either much like math or human language; just "close to conceptual essential concepts. |
10:47:11 | BlaXpirit | what can we say about Nim in its channel |
10:47:14 | BlaXpirit | except for "is good" |
10:47:45 | BlaXpirit | libraries are lacking, sure, but that's a matter of time |
10:48:05 | rkj-b | It can be learned in less than ten years??? |
10:48:34 | BlaXpirit | it hasn't existed for ten years -_- |
10:48:48 | BlaXpirit | and yet, there are people who know it |
10:48:52 | BlaXpirit | so there is your answer :p |
10:49:29 | Demon_Fox | Some could argue that you can't learn truly C in 10 years |
10:49:51 | * | NimBot joined #nim |
10:50:33 | vegai | obligatory http://norvig.com/21-days.html |
10:54:03 | BlaXpirit | docopt has been ported to nim!!! |
10:54:10 | BlaXpirit | mark this amazing moment in history |
10:55:07 | BlaXpirit | now, for testing and formalities |
10:55:24 | BlaXpirit | http://docopt.org/ btw |
10:59:16 | * | akiradeveloper_ quit (Ping timeout: 246 seconds) |
11:06:11 | * | Trustable joined #nim |
11:13:19 | * | renesac quit (Quit: Page closed) |
11:20:26 | skyfex | BlaXpirit: I didn't know about that project, that looks great ^_^ |
11:20:53 | BlaXpirit | testing might be a bit more difficult than i expected. https://github.com/docopt/docopt/blob/master/testcases.docopt |
11:21:24 | BlaXpirit | unless, of course, i write the testing program in python |
11:24:42 | skyfex | Why would it be harder in Nim? |
11:24:58 | BlaXpirit | skyfex, because I don't know my way around it |
11:25:00 | BlaXpirit | :3 |
11:25:06 | BlaXpirit | and because JSON parsing is a huge pain |
11:26:06 | BlaXpirit | are there any nontrivial examples of json parsing? |
11:26:58 | BlaXpirit | bah i guess it's not so bad; my biggest problems are these arbitrary field names "fnum" "bval" |
11:43:45 | Demon_Fox | I thought that nim would have a library for it by now |
11:45:03 | BlaXpirit | lapp exists |
11:45:13 | BlaXpirit | but it seemed strange to me |
12:19:06 | gokr | BlaXpirit: Good work man! |
12:19:10 | BlaXpirit | thx |
12:19:25 | gokr | I just took Lapp since it was the one existing that did it like that. |
12:22:17 | wan | BlaXpirit: didn't someone else write a docopt for nim long ago? https://github.com/acolley/docopt.nim (haven't tested it) |
12:22:31 | BlaXpirit | there are a lot of "todo" in it. it's unfinished and abandoned |
12:23:03 | BlaXpirit | although maybe it was almost done and i shouldve looked at it :p |
12:23:56 | flaviu | BlaXpirit: not enough comments, and nim tends to be very dense. |
12:57:02 | * | rkj-b quit (Quit: ChatZilla 0.9.91.1 [Firefox 34.0.5/20141126041045]) |
13:00:09 | * | Jesin quit (Quit: Leaving) |
13:12:07 | * | EXetoC joined #nim |
13:24:38 | dom96 | BlaXpirit: Does it work at compile-time? :P |
13:24:44 | BlaXpirit | dom96, it might |
13:24:50 | BlaXpirit | dom96, no |
13:24:51 | BlaXpirit | wait |
13:24:53 | BlaXpirit | no T_T |
13:24:56 | dom96 | It should. |
13:24:58 | BlaXpirit | re |
13:25:15 | dom96 | whyyyy |
13:25:26 | dom96 | write a parser using parseutils |
13:25:30 | BlaXpirit | nnnnope |
13:25:41 | BlaXpirit | i have no idea how docopt works |
13:25:57 | BlaXpirit | i worked as py2nim |
13:26:06 | BlaXpirit | get it |
13:26:42 | dom96 | Perhaps it would be better to write a DSL in which you specify the args. |
13:27:03 | BlaXpirit | perhaps not?? |
13:27:27 | dom96 | Why? |
13:27:42 | BlaXpirit | exactly, why? |
13:28:31 | dom96 | Because depending on re sucks. |
13:28:53 | BlaXpirit | well rewriting that to nim sucked in the first place |
13:29:06 | dom96 | it did? Why? |
13:29:31 | BlaXpirit | because it is possible to use C++ implementation lol |
13:29:48 | BlaXpirit | dom96, tell you what |
13:29:59 | BlaXpirit | better rewrite re in nim than complain about its use |
13:31:02 | dom96 | i'm not sure what you mean. |
13:31:06 | dom96 | C++ implementation? |
13:31:12 | BlaXpirit | c++ implementation of docopt |
13:31:13 | * | gmpreussner__ joined #nim |
13:31:24 | BlaXpirit | may be possible to wrap it and whatnot |
13:31:30 | * | gmpreussner_ quit (Ping timeout: 244 seconds) |
13:31:38 | BlaXpirit | but no, i went the hard way |
13:33:55 | BlaXpirit | but i don't think there is any implementation that doesn't use regex |
13:41:16 | * | johnsoft quit (Ping timeout: 265 seconds) |
13:42:19 | * | johnsoft joined #nim |
13:43:56 | * | matkuki joined #nim |
13:44:45 | matkuki | flaviu: A question about your OOP macro? |
13:44:54 | flaviu | matkuki: sure |
13:45:03 | flaviu | I was away when you first asked |
13:45:10 | matkuki | no problem |
13:45:58 | matkuki | Is there a way for the procs/methods not to have to be declared sequentially? |
13:46:37 | matkuki | For example, you cannot call a proc/method that is declared later in the class in a preceding proc. |
13:46:46 | * | alelos joined #nim |
13:48:19 | matkuki | Other than that, the macro work beautifully! |
13:48:29 | matkuki | sorry, works. |
13:48:58 | * | BitPuffin joined #nim |
13:50:02 | flaviu | matkuki: sure, I guess you could iterate over all the methods and procs and create forward declarations. |
13:52:23 | flaviu | generate the ast for the body as in `for node in body.children:`, but place it in a temporary variable before adding it to the result. So you then iterate over the different procs and methods and creates forward declarations. |
13:53:17 | flaviu | does that make sense? I'm not sure I phrased things well. |
13:53:58 | matkuki | Yes makes perfect sense, will try it thanks. |
13:54:55 | matkuki | If I get stuck I'll ask you for help. I'm still only a beginner in macros. |
13:55:22 | * | Trustable quit (Remote host closed the connection) |
13:59:14 | * | akiradeveloper joined #nim |
13:59:34 | * | akiradeveloper quit (Client Quit) |
13:59:57 | * | akiradeveloper joined #nim |
14:00:27 | akiradeveloper | Hi |
14:01:12 | akiradeveloper | I want to read out a part of sequence of some type T as in the following code https://gist.github.com/akiradeveloper/7cd6b4cea289759e6364 |
14:01:32 | akiradeveloper | do you explain why this fails complation? |
14:02:51 | BlaXpirit | do not use cast |
14:02:52 | BlaXpirit | gee |
14:03:03 | BlaXpirit | what is this anyway? |
14:03:46 | BlaXpirit | maybe u wanted cast[uint](p)[] |
14:03:52 | BlaXpirit | no.. |
14:03:59 | BlaXpirit | nvm |
14:04:08 | akiradeveloper | A request from fuse client has a sequence of data that starts from a header. I want to read out the data as the header type |
14:04:51 | * | gunn quit (Ping timeout: 264 seconds) |
14:06:23 | BlaXpirit | akiradeveloper, |
14:06:25 | BlaXpirit | let v = getT[uint64](mySeq) # ok |
14:06:34 | * | gunn joined #nim |
14:07:14 | * | sillesta joined #nim |
14:08:51 | akiradeveloper | it is ok... why? why mySeq.getT(uint64)() still fails |
14:09:14 | BlaXpirit | dot is weird, that's all i can say. all kinds of bugs related to it. |
14:09:53 | akiradeveloper | BlaXpirit, much thanks. I was all lost. |
14:10:58 | * | akiradeveloper quit () |
14:13:53 | EXetoC | it does make complex expressions more readable imo, and most people don't seem to have a problem with it |
14:14:57 | BlaXpirit | EXetoC, dot is great, it is also easily abusable, but i am not talking about this |
14:15:11 | BlaXpirit | just saying it is buggy |
14:16:51 | EXetoC | I know it doesn't really work with templates, that's all |
14:17:39 | BlaXpirit | also generics... |
14:18:04 | BlaXpirit | as seen in this very example |
14:18:34 | EXetoC | same underlying issue then maybe |
14:19:33 | * | gmpreussner__ quit (Ping timeout: 244 seconds) |
14:20:18 | * | gmpreussner__ joined #nim |
14:25:32 | * | jefus__ joined #nim |
14:27:42 | * | gmpreussner___ joined #nim |
14:27:49 | * | gmpreussner__ quit (Ping timeout: 244 seconds) |
14:29:27 | * | jefus_ quit (Ping timeout: 272 seconds) |
14:42:35 | * | Demon_Fox quit (Quit: Leaving) |
14:42:48 | * | gmpreussner___ quit (Ping timeout: 244 seconds) |
14:43:05 | * | gmpreussner___ joined #nim |
15:02:35 | * | jefus__ is now known as jefus |
15:10:38 | * | keyle quit (Quit: Morbo: Chitchat achieved!) |
15:20:36 | * | gmpreussner joined #nim |
15:21:02 | * | gmpreussner___ quit (Ping timeout: 244 seconds) |
15:21:36 | * | skyfex quit (Quit: (null)) |
15:24:29 | * | MattAitc_ joined #nim |
15:29:03 | * | MattAitc_ quit (Remote host closed the connection) |
15:30:33 | matkuki | flaviu: A little help please. I added this code (https://bpaste.net/show/1f39ee1413fd) before the existing "for node in body.children:" line. |
15:30:45 | matkuki | I get the error "Error: illformed AST: proc MyProc*{this :MyClass} =" ! |
15:32:10 | EXetoC | have you stringified the nodes in order to see why it happens? |
15:34:10 | flaviu | matkuki: Instead of p.body = newStmtList(), try p[6] = newEmptyNode() |
15:34:34 | flaviu | general workflow is to use dumpTree to figure out what AST you want to target, and then write the code to get that AST. |
15:35:28 | matkuki | flaviu: let me try it ... |
15:36:01 | BlaXpirit | what is the conventional name for a function that converts something to int? |
15:36:26 | EXetoC | toInt? |
15:36:29 | BlaXpirit | well actually... in my case it's not really conversion |
15:36:58 | BlaXpirit | "get int value" |
15:37:04 | BlaXpirit | toInt may be best, yeah... |
15:39:57 | EXetoC | what are you converting? |
15:40:34 | BlaXpirit | EXetoC, a variant type |
15:40:38 | BlaXpirit | much like json value |
15:40:55 | BlaXpirit | JsonNode |
15:41:36 | * | kapil__ quit (Quit: Connection closed for inactivity) |
15:41:46 | BlaXpirit | i want this stuff to be more convenient than checking for kind and getting member intV or something |
15:41:50 | * | booly-yam-2084 joined #nim |
15:44:26 | EXetoC | getInt? |
15:45:23 | EXetoC | that seems more appropriate. what will it do if the field is inaccessible? |
15:45:42 | BlaXpirit | EXetoC, the user is supposed to know the type of the field beforehand |
15:45:51 | BlaXpirit | so in case it's not int, exception will be thrown |
15:46:25 | BlaXpirit | i could avoid variant type and just generate variables with macros instead, |
15:46:32 | BlaXpirit | but sadly, "re" is not available at compile time |
15:46:52 | EXetoC | an exception will be raised anyway |
15:47:09 | EXetoC | you want to use some other exception type? |
15:47:34 | BlaXpirit | nah |
15:47:38 | matkuki | flaviu: p[6] = newEmptyNode() removes the "=" from the error message. Looking at the dumpTree of the "forward_declarations" statement list variable, it seems that the bodies of the procs are still there. Why? |
15:47:44 | BlaXpirit | i was thinking of making converters... |
15:47:55 | EXetoC | ok well in that case |
15:49:34 | EXetoC | 'toInt' would be better then |
15:49:42 | * | booly-yam-2084 quit (Remote host closed the connection) |
15:49:56 | BlaXpirit | ok thanks |
15:50:25 | flaviu | matkuki: Sorry, can't help you right now. I'll be back later |
15:50:52 | matkuki | no problem |
15:52:51 | * | yonson quit (Ping timeout: 264 seconds) |
16:01:03 | * | matkuki quit (Quit: ChatZilla 0.9.91.1 [Firefox 35.0/20150108202552]) |
16:09:30 | * | saml_ joined #nim |
16:11:41 | * | darkf quit (Quit: Leaving) |
16:15:39 | * | gunn quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
16:24:40 | BlaXpirit | https://github.com/BlaXpirit/docopt.nim |
16:25:32 | EXetoC | not man enough to not use re? ;) |
16:25:46 | EXetoC | that's great. I've wanted an equivalent of docopt |
16:26:23 | BlaXpirit | i do not understand how docopt works |
16:26:27 | BlaXpirit | it is a direct rewrite |
16:26:43 | BlaXpirit | docopt.py uses re, i use re |
16:27:06 | EXetoC | j/k ofc |
16:28:17 | * | sdw joined #nim |
16:29:02 | EXetoC | can descriptions and such span multiple lines? |
16:29:18 | BlaXpirit | uh probably |
16:29:33 | BlaXpirit | docopt has detailed documentation |
16:30:51 | EXetoC | your port that is, but I will try it some time |
16:30:54 | BlaXpirit | looks like they can. i simply tried |
16:31:14 | BlaXpirit | EXetoC, my port is supposed to be identical |
16:31:42 | BlaXpirit | Tests passed: 170/174 |
16:31:51 | BlaXpirit | too tired to debug any more |
16:32:05 | BlaXpirit | but these are kinda corner cases |
16:32:56 | * | dyu joined #nim |
16:33:24 | BlaXpirit | hopefully i can add it to docopt organization and boost Nim a bit |
16:34:45 | EXetoC | you could also implement args["foo", bool], with a default type |
16:35:13 | BlaXpirit | EXetoC, what do you mean "default type" |
16:35:21 | EXetoC | it's just a suggestion. I like to specify the actual type |
16:35:31 | BlaXpirit | also, args is an ordinary Table |
16:35:31 | EXetoC | T: typedesc = string |
16:35:38 | EXetoC | ok |
16:36:21 | dom96 | "Someday you will be a Nim Legend, like dom96." |
16:36:24 | BlaXpirit | lel |
16:36:25 | dom96 | Looks like I have a fan girl. |
16:36:37 | EXetoC | the instantiation makes it a unique type though, so you can just "extend" it |
16:37:05 | BlaXpirit | nice, nice. |
16:38:36 | BlaXpirit | i was thinking that there definitely should be a converter to bool, converter $ for string, converter toInt, [] index access |
16:39:00 | dom96 | BlaXpirit: Converter from what to bool? |
16:39:06 | BlaXpirit | from variant type |
16:39:39 | dom96 | oh, when you say converter you don't mean an actual converter. |
16:39:46 | BlaXpirit | I do :| |
16:39:46 | * | nimnoob joined #nim |
16:39:54 | dom96 | That wouldn't work. |
16:39:57 | BlaXpirit | https://github.com/BlaXpirit/docopt.nim/blob/4f51d4a4e1ffeea19dbe5bd2fd4f33d7a25c1ba3/src/docopt.nim#L13 - I want convenient access to these |
16:40:03 | dom96 | You can't have two converters on the same type |
16:40:07 | BlaXpirit | :o |
16:40:12 | BlaXpirit | no way |
16:40:21 | dom96 | hrm, or maybe you can. |
16:40:27 | BlaXpirit | i was sure you can |
16:40:29 | dom96 | But that will lead to errors. |
16:40:35 | dom96 | Runtime errors. |
16:40:37 | dom96 | It's not a good idea. |
16:41:10 | EXetoC | you could reduce bloat by allowing the table to be generated at compile-time :p |
16:41:21 | BlaXpirit | yes, yes, that's what i thought right away |
16:41:31 | EXetoC | dom96: that's true either way, isn't it? |
16:41:38 | BlaXpirit | search that source file for "re(r" |
16:41:44 | BlaXpirit | to see what i'd have to deal with |
16:41:49 | dom96 | EXetoC: It is. But converters are implicit. |
16:42:31 | BlaXpirit | dom96, the types of these values are the same every single invokation of the program |
16:42:55 | dom96 | huh? |
16:43:04 | dom96 | Let's use json as an example. |
16:43:09 | dom96 | You have converters for each node type. |
16:43:12 | BlaXpirit | json is json |
16:43:16 | BlaXpirit | but i'm talking about my case |
16:43:24 | dom96 | You pass a Node which is a JFloat to a proc which takes an int. |
16:43:38 | dom96 | The converter invoked will try to access .num and that will result in a runtime error. |
16:43:39 | sillesta | coming from c++ OO (eg. EntityFoo extends Entity) game dev, is there any significant differences in how it would/should be done? does nim offer something different than just ordinary OO? |
16:43:45 | BlaXpirit | dom96, yes... |
16:43:59 | * | JinShil quit (Quit: Konversation terminated!) |
16:44:04 | BlaXpirit | but consider that the kinds of these doesn't depend on user input |
16:44:05 | dom96 | I'm assuming you've got fields which are not accessible based on the kind since it is an object variant? |
16:44:14 | BlaXpirit | if it breaks once, the programmer will know and fix it |
16:44:44 | BlaXpirit | sillesta, generic are nice |
16:44:47 | BlaXpirit | generics |
16:44:59 | EXetoC | couldn't <x> be anything? |
16:45:18 | BlaXpirit | even if it's 9, it's a string "9" |
16:45:33 | sillesta | BlaXpirit: from the little nim i know, i'm guessing dynamic dispatch is similar to marking methods as 'virtual' in c++ |
16:45:34 | BlaXpirit | "anything" is always a string |
16:45:47 | BlaXpirit | sillesta, yes. method is almost exactly like virtual |
16:46:04 | BlaXpirit | but dispatch works differently, no vtables blah blah i don't know this |
16:46:20 | * | UberLambda quit (Quit: Leaving the Matrix) |
16:47:49 | * | zahary quit (Read error: Connection reset by peer) |
16:48:15 | EXetoC | when is val(int) invoked? |
16:48:18 | * | zahary joined #nim |
16:48:38 | BlaXpirit | it's for internal use |
16:48:45 | BlaXpirit | oh but you probably mean internally |
16:49:00 | BlaXpirit | val(0) val(1) |
16:50:08 | BlaXpirit | hm can it really never be a different value? |
16:50:18 | EXetoC | I thought that type was used in some other way |
16:51:02 | BlaXpirit | [:25:42] <BlaXpirit> i do not understand how docopt works |
16:51:08 | EXetoC | maybe range constraints and such can be specified outside the string, but then you need to reference the flags somehow |
16:51:57 | * | endou______ quit (Ping timeout: 272 seconds) |
16:52:53 | * | CARAM__ quit (Ping timeout: 245 seconds) |
16:54:26 | * | BlaXpirit_ joined #nim |
16:54:28 | BlaXpirit_ | it appears i dropped connection |
16:54:55 | BlaXpirit_ | EXetoC, int value is for this: prog -p... |
16:55:16 | BlaXpirit_ | prog -p -ppp args["-p"].int_v == 4 |
16:55:38 | BlaXpirit_ | but how it manages to get to 4 if i only create them with 0 and 1 values - who the heck knows :p |
16:56:44 | BlaXpirit_ | ah right. int_v += increment.int_v |
16:56:58 | EXetoC | why do you need a variant for that purpose? |
16:57:24 | BlaXpirit_ | EXetoC, ... |
16:57:26 | * | BlaXpirit quit (Ping timeout: 264 seconds) |
16:57:32 | BlaXpirit_ | i need a variant to avoid thinking |
16:57:43 | BlaXpirit_ | in python everything is a variant of everything |
16:58:48 | BlaXpirit_ | avoiding a variant would require big changes in implementation |
16:59:00 | BlaXpirit_ | these things are passed around in all kinds of nodes |
17:03:35 | EXetoC | I'm only asking |
17:04:42 | BlaXpirit_ | now that i think about it, int_v is actually count |
17:06:54 | * | nimnoob_ joined #nim |
17:06:54 | * | nimnoob quit (Read error: Connection reset by peer) |
17:11:34 | * | brson joined #nim |
17:11:35 | * | nimnoob_ quit (Ping timeout: 256 seconds) |
17:25:13 | * | gokr_ joined #nim |
17:35:56 | * | nimnoob_ joined #nim |
17:38:02 | * | endou______ joined #nim |
17:40:23 | * | nimnoob_ quit (Ping timeout: 240 seconds) |
17:42:06 | EXetoC | BlaXpirit_: why is it important for docopt.nim to remain identical with docopt? |
17:42:34 | BlaXpirit_ | EXetoC, because that is everything the project is - a direct copy of docopt |
17:42:47 | BlaXpirit_ | i intend to add it to docopt organization |
17:43:08 | BlaXpirit_ | also, i have no clue how to add features to it :3 |
17:43:57 | BlaXpirit_ | EXetoC, i am planning to make ..._v members private |
17:45:07 | BlaXpirit_ | then "len" would access int (or len of seq), `@` would access seq, converter toBool, `$` string (and anything else) |
17:45:32 | BlaXpirit_ | seems cool to me, but maybe it's a bit too crazy |
17:45:40 | EXetoC | len for int? |
17:45:57 | BlaXpirit_ | yeah |
17:46:16 | BlaXpirit_ | [:54:14] <BlaXpirit_> EXetoC, int value is for this: prog -p... [:54:35] <BlaXpirit_> prog -p -ppp args["-p"].int_v == 4 |
17:46:26 | BlaXpirit_ | and i'm pretty sure that's the only thing int value is used for |
17:46:29 | EXetoC | just think about whether or not the trade-off is a net positive. implicit conversions are a source of confusion obviously |
17:46:40 | EXetoC | right. I forgot |
17:47:08 | * | CARAM__ joined #nim |
17:48:19 | EXetoC | you mean a converter for bool only? |
17:50:06 | BlaXpirit_ | yes |
17:53:34 | EXetoC | how about another repo or branch for the direct port? |
17:54:34 | BlaXpirit_ | EXetoC, how about a fork for additional functionality |
17:54:42 | BlaXpirit_ | (which I do not intend to make) |
17:54:55 | ekarlso | what u guys doing ? ^ |
17:55:25 | BlaXpirit_ | ekarlso, http://docopt.org/ in Nim: https://github.com/BlaXpirit/docopt.nim |
17:57:46 | BlaXpirit_ | it's not like i'm more fit to make additional functionality than anyone else. |
18:02:32 | EXetoC | fork and rename to just 'docopt'? |
18:03:47 | BlaXpirit_ | this is not just 'docopt', this is a port of docopt to nim |
18:04:04 | BlaXpirit_ | and that's the naming convention they use in docopt organization |
18:04:12 | BlaXpirit_ | http://github.com/docopt/ |
18:04:57 | BlaXpirit_ | but yeah, you can probably fork and rename it, i suppose |
18:08:06 | ekarlso | awesome BlaXpirit_ ! |
18:18:30 | flaviu | BlaXpirit_: I'll see if I can fix the bugs. |
18:18:40 | BlaXpirit_ | flaviu, u mean docopt? |
18:18:43 | flaviu | yep |
18:18:45 | BlaXpirit_ | ok cool |
18:18:46 | EXetoC | BlaXpirit_: I noticed that, and I was referring to the extended lib, which would be the fork |
18:19:16 | BlaXpirit_ | EXetoC, i still like to have name of the programming language in repos of the things i make |
18:19:21 | BlaXpirit_ | cuz why not |
18:19:37 | BlaXpirit_ | and not having them can be harmful if i want to make the same thing in a different language |
18:19:42 | EXetoC | same name? but adding that to nimble instead |
18:20:03 | BlaXpirit_ | EXetoC, to that I can't agree :s |
18:21:05 | BlaXpirit_ | it would be something different, which is not docopt anymore |
18:21:17 | flaviu | BlaXpirit_: Btw, instead of this mess: re.re(r"\[default: (.*)\]", {reIgnoreCase}), you can do `re"(?i)\[default:\s(.*)\]` |
18:21:38 | BlaXpirit_ | oh ok |
18:21:49 | BlaXpirit_ | flaviu, can't remove "re.re" though :p |
18:21:57 | BlaXpirit_ | some bug prevents direct use |
18:22:50 | EXetoC | fine some other name then :p |
18:22:57 | * | dyu quit (Quit: Leaving) |
18:23:01 | BlaXpirit_ | flaviu, does using flags like that cancel out the default flags? |
18:23:10 | BlaXpirit_ | because i don't need extended |
18:23:18 | BlaXpirit_ | (it actually caused 1 bug) |
18:23:26 | BlaXpirit_ | or i suppose i could work around that |
18:23:29 | flaviu | nope, which is why I used \s instead of space. |
18:23:44 | BlaXpirit_ | flaviu, should be "\ " |
18:23:58 | EXetoC | you should close the issue then |
18:24:02 | BlaXpirit_ | kinda lame that you can't cancel out extended though |
18:24:18 | EXetoC | oh. nvm |
18:24:26 | BlaXpirit_ | i was just so quick, EXetoC :p |
18:25:28 | BlaXpirit_ | EXetoC, you know what i was thinking? it's not so important to have validation be part of doc message, and it can sometimes be too much |
18:25:49 | EXetoC | can we add the docopt fork to the official organization? |
18:25:54 | BlaXpirit_ | it's quite easy to just walk through options and check their values |
18:26:09 | BlaXpirit_ | EXetoC, uhh no? |
18:26:31 | BlaXpirit_ | we can, however, add fork to README of the main one if it's something good |
18:26:32 | EXetoC | BlaXpirit_: the official nim organization |
18:27:05 | EXetoC | BlaXpirit_: yes, with a good old 'case' block, and possibly some abstractions for the constraint checking |
18:27:12 | BlaXpirit_ | EXetoC, hmmm why would it be there though? i think the organization is "bloated" :D |
18:27:34 | BlaXpirit_ | but it's not like i can forbid it |
18:27:44 | BlaXpirit_ | doesnt really matter to me |
18:27:47 | EXetoC | dom96: thoughts? is it bloated? |
18:29:23 | dom96 | EXetoC: Yes. |
18:31:09 | EXetoC | I could move 'mongo' to my user, as well as removing it from nimble until I actually have something that can be used |
18:36:47 | * | nimnoob_ joined #nim |
18:41:23 | * | flaviu quit (Read error: Connection reset by peer) |
18:41:27 | * | nimnoob_ quit (Ping timeout: 264 seconds) |
18:41:38 | * | flaviu joined #nim |
18:49:53 | * | jefus quit (Ping timeout: 240 seconds) |
18:59:35 | ekarlso | https://bpaste.net/show/d8cfadab2734 < is there a better way to define that ? |
18:59:54 | * | badkins joined #nim |
19:00:43 | fowlmouth | ekarlso, proc`%`(s: SignatureAlgorithm): JsonNode{.borrow.} |
19:00:49 | ekarlso | borrow ? |
19:00:52 | EXetoC | 'Type'? |
19:01:10 | EXetoC | it is not the same as 'type' now though |
19:01:54 | ekarlso | hmm |
19:01:59 | ekarlso | can you do a enum on a string ? |
19:02:47 | EXetoC | enumerators can be strings, yes |
19:03:06 | EXetoC | try it :p |
19:03:24 | BlaXpirit_ | mm i totally forgot this |
19:04:12 | * | Jesin joined #nim |
19:08:10 | * | rkj-b joined #nim |
19:20:26 | * | alexruf joined #nim |
19:25:24 | * | yonson joined #nim |
19:30:33 | * | Demos joined #nim |
19:31:29 | * | benji_ joined #nim |
19:31:38 | * | benji_ is now known as benji |
19:32:30 | * | matkuki joined #nim |
19:34:35 | matkuki | flaviu: Are you here? |
19:34:42 | flaviu | yep |
19:35:52 | matkuki | Here is my class macro that doesn't work: https://bpaste.net/show/c60303139ac8 |
19:36:40 | matkuki | The added stuff starts at line 82 |
19:37:29 | benji | Hi all! I'm playing with nim and I have run into an issue I can't figure out: I have a program that compiles and works (http://paste.ubuntu.com/9769301/) but when I wrap the bulk of the program in a function (http://paste.ubuntu.com/9769293/) I get a compile error: http://paste.ubuntu.com/9769315/ |
19:40:36 | * | alexruf quit (Quit: Textual IRC Client: www.textualapp.com) |
19:41:03 | matkuki | flaviu: here is my example class and the error message: https://bpaste.net/show/48cf029dd157 |
19:41:11 | flaviu | matkuki: https://gist.github.com/5fa79727c472882ae21a |
19:41:32 | flaviu | See how instead of copying that code, I instead add the procedures to a list? |
19:41:47 | flaviu | I then use that list to create the regular definitions and the forward declarations. |
19:42:33 | matkuki | Ahh, brilliant! |
19:42:36 | EXetoC | matkuki: are you also inspecting the equivalent code? |
19:43:16 | EXetoC | ok you are |
19:43:35 | matkuki | EXetoC: I'm not sure what you mean by that. I'm not that good at macros |
19:43:41 | dom96 | benji: Your procedure names shouldn't start with a capital letter. |
19:44:02 | * | benji applies ~ |
19:44:40 | dom96 | That's an interesting issue though. |
19:45:02 | dom96 | oh, I know why. |
19:45:12 | dom96 | When you put a proc into another procedure you are turning it into a closure. |
19:45:27 | dom96 | When it's in the global scope it is using global variables |
19:45:30 | dom96 | so it's not a closure |
19:46:08 | benji | true... I don't see how that changes it's signature though (which is how I interpret the compiler error) |
19:46:40 | benji | and in this case I still want it to be a closure because it closes over the variable "file" |
19:47:47 | EXetoC | matkuki: some parts of the AST can be assembled with the help of templates: http://nim-lang.org/macros.html#getAst,expr |
19:48:06 | dom96 | benji: You can't pass a closure to a C function which expects a function pointer. |
19:48:19 | EXetoC | which will improve the readability of the macro body |
19:48:20 | benji | ah! now that makes sens |
19:48:26 | benji | e |
19:48:41 | dom96 | the error definitely needs to be improved though |
19:49:30 | matkuki | EXetoC: I used treeRepr and lispRepr up to now. Will try it. |
19:49:58 | EXetoC | matkuki: that's for debugging though |
19:52:11 | EXetoC | .eval macro foo: stmt =; template echoStuff = echo "hi"; result = newStmtList(getAst(echoStuff())); foo() # matkuki |
19:52:14 | Mimbus | EXetoC: hi |
19:52:50 | BlaXpirit_ | :o |
19:53:06 | EXetoC | BlaXpirit_: hi-tech innit |
19:53:14 | BlaXpirit_ | so templates really are convenience wrappers for macros |
19:53:23 | benji | dom96: is there a way to get a pointer to the closure or something similar? |
19:54:23 | dom96 | Even if there was that wouldn't work. The closure is coupled with its environment which the C code will know nothing about. |
19:54:25 | flaviu | benji: Even if you do, where is it going to get it's implicit environment argument? |
19:54:43 | benji | magic! |
19:54:44 | dom96 | I'm afraid you simply cannot pass closures to C libraries. |
19:54:46 | benji | ;) |
19:54:48 | EXetoC | BlaXpirit_: they were not designed specifically for that |
19:55:44 | benji | I guess it's back to using a few carefully chosen globals then. Thanks for the help! |
19:56:50 | benji | dom96: oh, I was curious why procedures shouldn't start with a capital, is that a style thing or is there some semantic that I don't know about yet? |
19:57:29 | dom96 | benji: It is a style thing. Types are supposed to start with a capital. |
19:57:40 | def- | benji: https://github.com/Araq/Nim/wiki/NEP-1-%3A-Style-Guide-for-Nim-Code |
19:57:52 | benji | cool, thanks both of you |
20:04:50 | EXetoC | BlaXpirit_: call it directly rather than passing to an expr/stmt and the template body will be evaluated at the current scope (templates return stmt by default) |
20:04:59 | * | rkj-b quit (Quit: ChatZilla 0.9.91.1 [Firefox 34.0.5/20141126041045]) |
20:06:20 | reactormonk | Can I execute arbitrary code after the nim compiler compiles to C, before invoking the GCC? |
20:06:31 | matkuki | flaviu: Works great! You use a lot of indexes "[x]" on nodes. Is there a nim-by-example for a bit more detailed look into macros? |
20:07:14 | flaviu | matkuki: No, but the direct indexes can be seen in the dumpTree output. |
20:07:33 | flaviu | I like to place a comment with the tree next to whenever I use indexes. |
20:07:41 | EXetoC | the node formats are fixed. I think there are more descriptive ways to achieve the same thing though |
20:07:44 | matkuki | Ok, thanks. |
20:08:23 | EXetoC | in the form of procs in the macro module. I don't know if something is missing, but that'd then be preferable |
20:08:59 | EXetoC | this for example http://nim-lang.org/macros.html#name=,PNimrodNode,PNimrodNode |
20:10:43 | matkuki | EXetoC: Thanks. Yes, if ".body" is used instead of "[6]" it also works. It's more readable to me. |
20:12:11 | matkuki | EXetoC: I tried the macro you showed. Can you explain it's purpose? I compiled it and it just echo's "hi"? |
20:16:40 | EXetoC | the purpose is to improve readability. see the output of result.repr |
20:17:50 | matkuki | Ah, great! |
20:19:10 | EXetoC | this example is simple though. the difference in readability will be more pronounced when the AST is more complex |
20:27:45 | Araq | benji: you can use system.rawEnv and system.rawProc to convert a closure bakc into its ingredients |
20:27:53 | Araq | and thus get excellent C interop |
20:28:11 | Araq | it's just that it is not widely known here in #nim ... :P |
20:28:25 | benji | Araq: cool, I'll look those up in the docs. Thanks! |
20:29:06 | flaviu | Araq: I'm not sure what happens here: https://gist.github.com/flaviut/038804143b26ddf6fafa |
20:29:27 | flaviu | It's not supposed to have a kind field when T is a ref, but the c output still has one. |
20:32:03 | Araq | flaviu: I guess the compiler evaluates 'isRef' for the generic T? |
20:32:21 | Araq | which is false and then it's never checked for the actual instantation |
20:35:27 | * | yonson quit (Ping timeout: 264 seconds) |
20:36:41 | Araq | (it's a bug of course ...) |
20:37:09 | * | jefus joined #nim |
20:39:17 | flaviu | Araq: That was my hunch. I'll report it. |
20:45:19 | * | rpag joined #nim |
20:49:33 | * | BlaXpirit joined #nim |
21:00:39 | * | gokr_ quit (Ping timeout: 245 seconds) |
21:12:04 | matkuki | If a type has an enum field that has enumerations that don't start with 0 I get "Error: field not initialized: fieldname" ? |
21:12:11 | matkuki | Example: https://bpaste.net/show/98716eadbeb1 |
21:12:43 | matkuki | Is this a meant to be this way? |
21:12:45 | flaviu | matkuki: That sounds like it's as expected. |
21:13:06 | flaviu | It doesn't really make sense to have a 0 for an enum where a 0 has no meaning. |
21:14:18 | flaviu | matkuki: Note that `var testobj: MyType` works fine. |
21:16:56 | matkuki | flaviu: Sorry, there is a error in the pasted code the last line! It should be "test_object: MyType = MyType ()" |
21:17:26 | flaviu | matkuki: I know, I figured it out while running the example |
21:18:00 | flaviu | MyType() is an initializer for MyType, so it must not allow invalid values. |
21:21:42 | matkuki | flaviu: So it's mandatory to add these kind of enum fields to the initializer? |
21:22:10 | flaviu | matkuki: Yes, but if you don't want to, then you can just do `var testobj: MyType` |
21:22:33 | flaviu | and initialize the field however you'd like. |
21:22:36 | EXetoC | or have a construction proc of course |
21:23:57 | flaviu | https://github.com/Araq/Nim/issues/1693 |
21:23:57 | flaviu | Hopefully Araq'll agree to it if I'm annoying enough :P |
21:26:10 | matkuki | EXetoC: Can you give me an example of an initialization proc? |
21:27:45 | EXetoC | matkuki: initFoo(x: int): Foo = result = Foo(x: x) |
21:28:14 | EXetoC | I prefer to assign to result whenever possible, so as to make it easier to extend |
21:28:30 | matkuki | Thanks! |
21:29:14 | EXetoC | matkuki: and for pointer types: "newFoo(x: int): ref/ptr Foo = result = (ref/ptr Foo)(x: x)" |
21:30:30 | EXetoC | "(ptr Foo)()" being sugar for "new result; result[] = Foo(x: x)" ([] dereferences a pointer) |
21:30:48 | matkuki | Got it. |
21:37:59 | matkuki | EXetoC: I like "init(f :var Foo, x: int) = f = Foo(x: x)", so I can do "foo.init(12)". Is this considered bad Nim style coding? |
21:43:29 | EXetoC | matkuki: no, but the disadvantages are the inability to use 'let', and the fact that an additional statement is needed |
21:44:54 | EXetoC | Araq: would the pragma that you talked about before allow 'let' to be used for such an init proc, or would that require another addition? |
21:50:05 | * | BlaXpirit quit (Ping timeout: 244 seconds) |
21:50:11 | * | shodan45 quit (Quit: Konversation terminated!) |
21:50:41 | * | shodan45 joined #nim |
21:52:28 | EXetoC | has further reductions of the stdlib size been discussed on the forum? |
21:53:53 | * | shodan45 quit (Client Quit) |
21:54:33 | EXetoC | dom96: that would be an easy change, but is it possible to create meta packages? |
21:55:03 | dom96 | what is an easy change? |
21:55:54 | EXetoC | dom96: what I said prior to that |
21:56:16 | EXetoC | I don't know who other than BlaXpirit_ cares about making it even smaller |
21:56:45 | BlaXpirit_ | main thing i want is better documentation |
21:56:49 | dom96 | This still needs to be finished https://github.com/Araq/Nim/issues/623 |
21:57:17 | BlaXpirit_ | i don't often say i want this or that removed from stdlib |
21:57:28 | BlaXpirit_ | last time i said it, it was about a harmful buggy function |
21:57:37 | EXetoC | I'll continue the discussion there |
21:57:44 | * | alelos quit (Ping timeout: 245 seconds) |
21:58:14 | BlaXpirit_ | so graphics was never moved out? |
21:58:36 | EXetoC | 0.9.6 milestone? you prefer overestimations over underestimations? ;) |
22:00:35 | dom96 | I think we need confirm some of those with Araq |
22:12:13 | BlaXpirit_ | EXetoC, https://github.com/keleshev/schema#using-schema-with-docopt |
22:12:22 | BlaXpirit_ | validation after the fact, no problems |
22:13:27 | EXetoC | I was leaning more towards such a solution |
22:15:15 | BlaXpirit_ | of course, this heavily relies on python's dynamic nature :| |
22:16:10 | EXetoC | nim can do it too |
22:16:57 | EXetoC | and it only relies on a fixed set of types anyway |
22:17:19 | BlaXpirit_ | umm have u looked at it? |
22:17:25 | BlaXpirit_ | it turns a string into a file, etc. |
22:19:22 | EXetoC | I don't think it makes a difference |
22:19:45 | benji | +1 on docopt. I very much enjoyed using it on a couple of small projects. |
22:20:18 | * | alelos joined #nim |
22:22:32 | EXetoC | benji: are you aware of the fact that it has been ported? https://github.com/BlaXpirit/docopt.nim |
22:23:05 | * | Trustable joined #nim |
22:23:12 | EXetoC | we're discussing extending it in a fork, but it should be useful as is |
22:23:12 | benji | EXetoC: nope; nice! |
22:23:18 | benji | cool |
22:27:31 | BlaXpirit_ | EXetoC, my point was mainly that you don't need to add validation to docopt itself |
22:29:44 | * | alelos quit (Quit: WeeChat 1.1) |
22:30:27 | EXetoC | I was just thinking about abstractions for simplifying the validation |
22:32:07 | flaviu | BlaXpirit_: looks great! You should announce it on the forums. |
22:32:23 | BlaXpirit_ | sure |
22:32:27 | BlaXpirit_ | but i dont even know what to write |
22:32:35 | * | benji unlocks Nim achievement: "Code compiles on the first try after a significant edit." |
22:32:39 | BlaXpirit_ | need some good introduction of what docopt even is |
22:32:41 | BlaXpirit_ | benji, :D |
22:33:10 | fowlmouth | nothing impressive about docopt |
22:33:19 | fowlmouth | i only looked at the rust version btw |
22:34:16 | flaviu | What's the point of a more elaborate readme? http://docopt.org/ is excellent |
22:34:44 | BlaXpirit_ | people won't immediately understand that it actually parses that message |
22:34:56 | BlaXpirit_ | i cant see that plainly and visibly written anywhere |
22:35:20 | BlaXpirit_ | well, actually there is, but it's not like people will carefully read it |
22:35:37 | flaviu | BlaXpirit_: Btw, you have it marked as 0.1.0, when the latest version is 0.6.2 |
22:35:57 | BlaXpirit_ | flaviu, first of all it's not even based on 0.6.2 |
22:36:01 | BlaXpirit_ | :s |
22:36:10 | BlaXpirit_ | master |
22:36:20 | BlaXpirit_ | doesnt have to be the same version number, really |
22:36:41 | flaviu | BlaXpirit_: Yes, but there haven't been changes after the 0.6.2 tag. |
22:37:05 | BlaXpirit_ | you think so? https://github.com/docopt/docopt/blob/0.6.2/docopt.py vs https://github.com/docopt/docopt/blob/master/docopt.py |
22:37:22 | BlaXpirit_ | err i should've linked the main page |
22:37:32 | BlaXpirit_ | 381 commits vs 430 commits |
22:39:36 | flaviu | I see. |
22:41:38 | onionhammer | anyone know the allowed pattern for `blah` idents |
22:41:48 | EXetoC | operators |
22:42:38 | EXetoC | http://nim-lang.org/manual.html#operators |
22:43:20 | fowlmouth | onionhammer, the grammar is in the manual |
22:44:54 | fowlmouth | keyword || operator || ident iirc |
22:49:19 | onionhammer | yeahah thanks exetoc |
22:53:37 | * | tinAndi joined #nim |
23:10:26 | * | matkuki quit (Quit: ChatZilla 0.9.91.1 [Firefox 35.0/20150108202552]) |
23:19:40 | * | ARCADIVS joined #nim |
23:34:01 | gokr | sillesta: Did you see my OO articles? |
23:34:35 | sillesta | shoot me some links! |
23:34:52 | gokr | http://goran.krampe.se/category/nim |
23:38:23 | EXetoC | sugar for defining a getter and/or a setter in such a macro would be nice. it's such a common thing to do after all |
23:51:11 | * | gokr_ joined #nim |
23:55:37 | * | gokr_ quit (Client Quit) |