00:05:57 | dom96 | Varriount: why do you need the entire overlapped structure? |
00:06:05 | dom96 | and what "choice bits" are you referring to? |
00:08:55 | * | milieu joined #nimrod |
00:14:21 | Kelet | dom96: If I have some magic macro that can do var f = toProc("x^2 + 3x"), how can it know that f is of type var f: proc(x: float): float or something like that? |
00:14:30 | Kelet | For example is it possible to do something like |
00:15:01 | Kelet | var f = toProc("x^2 + 3y") and have it make a 2-sized parameter list based on order of introduction without explicitly knowing it at compile time? |
00:15:10 | Kelet | ah |
00:15:16 | Kelet | all this macro stuff has to be done at compile time |
00:15:20 | Kelet | doh. |
00:15:55 | Kelet | suppose the best you could do is something like var x = calc("x^2 + 3x", 5) which is meh |
00:16:10 | Kelet | (to calculate f(5)) |
00:16:35 | dom96 | No, it's pretty simple |
00:16:46 | dom96 | as long as all your params are floats and the return type is a flaot |
00:16:47 | dom96 | *float |
00:17:02 | dom96 | you may be able to use 'auto' but type inference still isn't perfect |
00:17:07 | Kelet | yeah, that's a fair assumption |
00:17:46 | Kelet | But how is this done if say I make a math-evaluating REPL? |
00:17:52 | Kelet | I thought macros were compile time only |
00:19:30 | dom96 | they are. |
00:19:37 | EXetoC | yes they are, but an AST is then returned which is compiled |
00:19:40 | dom96 | If you want a REPL then just write a normal app |
00:20:16 | reactormonk | but how would you execute the repl? |
00:20:51 | EXetoC | is it a REPL? |
00:21:58 | EXetoC | but yeah, you just parse a string at runtime. no need for any magic |
00:29:32 | fowl | mmmm digit := chr({'0'..'9'}).save((match:string) -> Node => IntNode(i: parseInt(match))) |
00:29:59 | * | brson joined #nimrod |
00:34:39 | dom96 | good night |
00:44:16 | Kelet | EXetoC: Can I make a proc at runtime? |
00:55:42 | * | Demos joined #nimrod |
01:00:25 | EXetoC | Kelet: no. parse it and decide what to do at run time |
01:01:14 | * | brson quit (Quit: leaving) |
01:09:06 | EXetoC | a proc can be loaded from a share lib, but that's only necessary for plugin systems and such |
01:13:04 | EXetoC | what you do is, you parse it and then you turn that into a tree, which you then have to validate and such |
01:13:42 | EXetoC | might be complicated. good luck ;) bye |
01:24:01 | Demos | can I put a nimdoc comment right before a type section that contains only one type? |
01:50:46 | * | rustypipe joined #nimrod |
01:51:28 | rustypipe | besides the tutorials on the website, are there any other tutorials for learning how to program with Nimrod? |
01:57:09 | Demos | well the manual is quite good, and there is that "nimrod for C programmers" document that Skrylar wrote |
01:57:27 | * | brson joined #nimrod |
01:58:11 | EXetoC | skyfex? |
01:59:14 | Demos | oh maybe |
01:59:36 | Demos | yeah it was skyfex, sorry skyfex |
02:21:40 | * | Zuchto quit (Remote host closed the connection) |
02:30:53 | * | Skrylar quit (Ping timeout: 264 seconds) |
02:34:29 | * | q66 quit (Quit: Leaving) |
02:37:32 | * | rustypipe left #nimrod (#nimrod) |
02:50:05 | * | Demos quit (Ping timeout: 264 seconds) |
03:05:07 | * | perturbation joined #nimrod |
03:05:35 | perturbation | ? |
03:06:03 | perturbation | sorry all, disregard... will be back later |
03:06:04 | * | perturbation quit (Client Quit) |
03:10:31 | * | brson quit (Quit: leaving) |
03:13:38 | * | Demos joined #nimrod |
03:14:05 | * | Skrylar joined #nimrod |
03:38:05 | Demos | what platform defines do we have? |
03:38:09 | Demos | any for OpenBSD? |
03:38:14 | Demos | BSD in general? |
03:47:19 | Varriount | Demos: What do you mean by defines? Like, defined(Windows), defined(Linux), etc? |
03:48:08 | Varriount | Demos: Also, remember you can dump defined symbols to output using "nimrod dump file.nim" |
03:48:21 | Varriount | dom96: You still there? |
03:49:27 | Varriount | dom96: I need access to the Event member, or otherwise some way of attaching extra data to the overlapped structure. Specifically, I need to associate a buffer pointer with the overlapped structure. |
03:49:45 | Demos | yeah |
03:49:56 | Demos | wait I am not dom96, as it turns out |
03:50:06 | Demos | and yeah I mean that kind of define |
03:50:16 | Demos | when not defined(OpenBSD) seemed to work |
04:07:19 | * | TylerE quit (Ping timeout: 252 seconds) |
04:08:28 | * | TylerE joined #nimrod |
04:37:38 | Varriount | dom96: I think I found away around not having direct access to the Overlapped structure with the callback (however you still might want to think of ways that others will want to extend asyncdispatch) |
04:39:52 | * | Demos quit (Quit: WeeChat 0.4.2) |
04:45:53 | reactormonk | ok, apparently we still need moar documentation. |
04:46:45 | Varriount | reactormonk: What gave you that silly idea? :3 |
04:58:54 | * | isenmann joined #nimrod |
05:04:06 | Varriount | Hi isenmann |
05:47:55 | * | Skrylar quit (Ping timeout: 250 seconds) |
07:00:03 | * | Skrylar joined #nimrod |
07:13:07 | * | vegai left #nimrod (#nimrod) |
07:29:17 | njoejoe | how to seek() and tell() on a PFileStream (and also on TFile)? |
07:35:25 | * | nande quit (Remote host closed the connection) |
07:35:59 | Araq | njoejoe: I don't think this is possible for PFileStream, dunno about TFile |
07:36:17 | Araq | I usually use memfiles when I don't read sequentially |
07:38:22 | njoejoe | ok, i will look into memfile. have multi GB files and was hoping for no mmap. |
07:42:02 | Araq | well you can easily wrap seek and tell if they are missing |
07:42:11 | Araq | nimrod's TFIle is C's FILE* |
07:42:55 | * | bjz quit (Ping timeout: 276 seconds) |
07:58:25 | * | Zuchto joined #nimrod |
08:02:41 | njoejoe | Oh I found TFile::setFilePos() which i think will do it. hopefully if I setFilePos() on the underlying file of the PFileStream, things will work out. |
08:04:18 | Skrylar | Araq: is there already a convenient jmp_buf and setjmp in the stdlib? i was poking around the other day and png needs |
08:04:31 | Skrylar | i fiddled it in to building, wasn't sure if we already had it |
08:08:57 | njoejoe | yes, that worked. but also i found PFileStream::setPosition() which also appears to work. So I'm using that. |
08:10:18 | * | wan quit (Ping timeout: 240 seconds) |
08:11:39 | Araq | njoejoe: ah good. I shouldn't answer questions to the language or the stdlib anymore ... |
08:11:52 | Araq | more often than not, I'm wrong |
08:12:15 | njoejoe | you've forgotten more than most will ever know :-) |
08:34:41 | * | DAddYE quit (Remote host closed the connection) |
08:35:17 | * | DAddYE joined #nimrod |
08:39:30 | * | DAddYE quit (Ping timeout: 240 seconds) |
09:15:48 | * | faassen joined #nimrod |
09:33:54 | * | zahary1 joined #nimrod |
09:35:54 | * | zahary quit (Ping timeout: 240 seconds) |
09:37:19 | * | BitPuffin quit (Ping timeout: 276 seconds) |
09:38:11 | * | BitPuffin joined #nimrod |
09:38:44 | * | faassen quit (Quit: Leaving.) |
09:43:03 | * | faassen joined #nimrod |
09:45:25 | Skrylar | neat |
09:45:29 | Skrylar | giflib's API is reasonable |
09:45:44 | * | faassen left #nimrod (#nimrod) |
10:26:42 | * | wan joined #nimrod |
10:53:19 | Araq | Skrylar: let us know when every C library in existance has a Nimrod wrapper :-) |
10:53:52 | EXetoC | the 2000 most popular once will do |
11:08:14 | * | zahary joined #nimrod |
11:10:14 | * | io2 joined #nimrod |
11:11:04 | EXetoC | *ones .. |
11:11:15 | * | zahary1 quit (Ping timeout: 265 seconds) |
11:14:07 | dom96 | Varriount: That is how you're meant to do it. You can capture anything inside the callback, there is no need to extend the overlapped structure |
11:23:42 | * | slacko15949 joined #nimrod |
11:30:38 | Araq | hi slacko15949 welcome |
11:36:14 | * | slacko15949 quit (Ping timeout: 240 seconds) |
11:49:29 | * | wan quit (Ping timeout: 255 seconds) |
12:03:45 | * | wan joined #nimrod |
12:08:57 | Skrylar | lol |
12:09:08 | Skrylar | i'm not working on *that* many |
12:10:40 | milosn | hey hey |
12:14:58 | * | wan quit (Ping timeout: 240 seconds) |
12:21:26 | * | kshlm joined #nimrod |
12:37:04 | * | q66 joined #nimrod |
12:37:04 | * | q66 quit (Changing host) |
12:37:04 | * | q66 joined #nimrod |
12:46:36 | Araq | hi kshlm welcome |
13:07:17 | * | io2 quit (Quit: ...take irc away, what are you? genius, billionaire, playboy, philanthropist) |
13:42:53 | * | darkf quit (Quit: Leaving) |
13:43:22 | * | menscrem joined #nimrod |
14:03:14 | milosn | Araq: hi, you got spare moment? you mentioned that i can do python style setattr() and getattr() in nimrod ... care to give me couple of one-liners i can start from? :) |
14:03:32 | milosn | or proc names in typeinfo module, and i can take it from there myself |
14:50:13 | * | Jesin quit (Quit: Leaving) |
14:55:17 | * | bjz joined #nimrod |
15:01:08 | fowl | milosn, if you consider the case where you do not use a dynamic field |
15:01:26 | fowl | milieu, setattr(obj, "x", 42) is obj.x = 42 |
15:13:18 | * | milieu quit (Ping timeout: 240 seconds) |
15:21:55 | * | brihat joined #nimrod |
15:22:00 | * | brihat quit (Client Quit) |
15:24:00 | * | chemist69 joined #nimrod |
15:33:09 | * | Matthias247 joined #nimrod |
15:35:14 | * | chemist69 quit (Quit: leaving) |
15:43:23 | * | noam_ joined #nimrod |
15:43:43 | * | bjz quit (Ping timeout: 252 seconds) |
15:47:18 | * | noam__ quit (Ping timeout: 240 seconds) |
16:03:17 | * | untitaker quit (Ping timeout: 264 seconds) |
16:08:45 | * | untitaker joined #nimrod |
16:11:37 | EXetoC | should this work? var arr = cast[ptr array[4, int8]](addr someObj)[] |
16:11:59 | EXetoC | not that all those indirections are needed, but it's the first thing I tried |
16:15:52 | * | Matthias247 quit (Read error: Connection reset by peer) |
16:18:43 | fowl | EXetoC, yes |
16:19:55 | EXetoC | yeah looks right. reporting it |
16:26:33 | fowl | whats wrong |
16:27:03 | EXetoC | invalid C code is generated |
16:27:11 | fowl | EXetoC, you are casting the data TFoo to a pointer |
16:27:29 | fowl | EXetoC, use cast[array[..]] or cast the address of foo/i |
16:27:50 | EXetoC | typo. doesn't matter |
16:30:01 | EXetoC | it should result in a runtime error in that case |
16:30:10 | EXetoC | unless one is really lucky :> |
16:30:48 | fowl | what u need this for |
16:30:58 | fowl | cast[ptr array[4,int8]](foo.addr) works for me |
16:32:38 | EXetoC | I upgraded to GCC 4.9 recently. it might have something to do with that |
16:39:45 | * | Jehan_ joined #nimrod |
16:46:00 | EXetoC | fowl: what are you using? |
16:51:44 | fowl | 4.8 |
16:53:26 | * | Jesin joined #nimrod |
16:55:04 | * | lesshaste joined #nimrod |
16:55:06 | lesshaste | hi |
16:55:16 | fowl | hello |
16:55:18 | lesshaste | what's the status of using C libraries in nimrod? |
16:55:23 | lesshaste | I mean libraries written in C |
16:55:44 | lesshaste | or just generally the use of libraries at all |
16:55:47 | fowl | lesshaste, highly possible |
16:55:54 | Jehan_ | It's fairly straightforward for the most part. |
16:56:09 | lesshaste | what do you have to do? I do a lot of scientific computing |
16:56:10 | fowl | many examples are available on nimrods package manager, babel |
16:56:19 | lesshaste | and I am very impressed by the speed you get from nimrod |
16:56:20 | Jehan_ | It's generally a question of whether c2nim can handle it automatically or whether you have to parts manually. |
16:56:35 | lesshaste | oh you mean actually translate the C? |
16:56:40 | lesshaste | fowl, thanks.. I should look there |
16:56:47 | Jehan_ | Well, Nimrod's speed is more or less C's, modulo how much you use GC. |
16:56:57 | Jehan_ | Since it compiles to C. |
16:56:59 | fowl | lesshaste, for a library you just need to bridge it to nimrod by defining the interface |
16:57:02 | lesshaste | Jehan_, right but some C libraries are seriously tuned. BLAS for example |
16:57:09 | lesshaste | fowl, ok thanks |
16:57:13 | Jehan_ | Yes, of course. |
16:57:37 | fowl | it looks like this; proc SDL_SetVideoMode (w,h,bpp: cint): PSurface {.importc, dynlib:"libSDL.so".} |
16:57:44 | lesshaste | ah ok |
17:00:40 | * | DAddYE joined #nimrod |
17:12:18 | * | BitPuffin quit (Ping timeout: 265 seconds) |
17:18:30 | milosn | fowl: ah setattr() ... is there an getattr()? |
17:18:47 | milosn | ill try setattr() when i get to that bit |
17:19:04 | Araq | just read the whole module |
17:19:09 | Araq | it is not big |
17:19:54 | Araq | basic approach: convert your thing to a TAny |
17:19:58 | fowl | milosn, to retrieve field X from obj Y, the syntax is Y.X |
17:20:17 | Araq | fowl: that is not what he means |
17:20:56 | Araq | bbl |
17:21:13 | milosn | Araq: reading type info docs as we speak ... there is no mention of setattr() nor getattr() :) |
17:21:19 | milosn | ok catch you later |
17:23:19 | EXetoC | probably not, but see marshal.nim for TAny in action. |
17:25:22 | * | Jesin quit (Quit: Leaving) |
17:25:41 | EXetoC | milosn: and here's a similar construct: http://build.nimrod-lang.org/docs/manual.html#dot-operators |
17:27:54 | * | Skrylar quit (Ping timeout: 276 seconds) |
17:32:59 | EXetoC | dom96: how do you indicate failure with async? 'quit' I guess |
17:33:42 | EXetoC | but everything is wrapped in async atm and I don't need really need to take that approach in this case |
17:35:05 | * | skyfex quit (Quit: Computer has gone to sleep.) |
17:35:39 | * | skyfex joined #nimrod |
17:45:36 | dom96 | EXetoC: raise an exception |
17:54:14 | reactormonk | lesshaste, you could code BLAS in nimrod, it is powerful enough. And if needed, include ASM blocks. nimrod has an `asm`, but that is for C code, so double asm if you need some assembler. |
17:57:01 | * | boydgreenfield joined #nimrod |
18:00:09 | EXetoC | dom96: it should work now? |
18:00:16 | dom96 | yes |
18:02:49 | milosn | hmm |
18:02:50 | milosn | base/Base_domains.nim(34, 23) Error: conversion from TAny to TBase_domains is invalid |
18:03:06 | milosn | does anything specific need to be done for type conversion to work? |
18:04:40 | milosn | basically I have user defined type TDomain which inherits from TBase_domains ... in TDomain init function i need to set some important variables so the new TDomain object is passed to init function of TBase_domains |
18:04:48 | milosn | thats how i ended there :) |
18:05:03 | EXetoC | dom96: ok so it doesn't propagate all the way to the default exception handler, end the current exception is nil when doing "try: await stuff() except E_Base: ..." |
18:05:23 | milosn | let me try without type conversion |
18:05:25 | * | Jesin joined #nimrod |
18:05:40 | dom96 | milosn: store your object as TBase_domains not a TAny |
18:05:59 | * | BitPuffin joined #nimrod |
18:06:00 | dom96 | milosn: or show us your code so we can help you better |
18:06:15 | dom96 | EXetoC: Yeah, getCurrentException won't work. |
18:07:04 | dom96 | EXetoC: but you should be able to catch EBase |
18:08:52 | milosn | dom96: TBase_domains is auto-magicaly generated code that describes the table 'domains' in the database, user defines TDomain which inherits TBase_domains ... TBase_domains knows nothing about how the user is going to use it |
18:09:40 | milosn | and since i can not init fields of an object in the type description ... i need init proc |
18:10:21 | milosn | where i can only receive as an argument user defined type TDomain ... as TAny, on which i need to init important fields |
18:10:24 | milosn | :) |
18:11:06 | dom96 | once again I will have to ask you to show me your code |
18:11:43 | milosn | oke, its couple of files, if i dont figure it out ... ill have to paste someplace |
18:11:57 | EXetoC | dom96: is it a temporary limitation? |
18:11:58 | dom96 | gist |
18:12:24 | dom96 | EXetoC: Yeah, should be a simple s/getCurrentException/future.error/ |
18:12:34 | dom96 | that the macro has to do |
18:14:07 | lesshaste | reactormonk, thanks |
18:16:42 | EXetoC | that works, assuming that it's called directly |
18:20:04 | EXetoC | are other approaches much more complicated? |
18:21:40 | dom96 | IMO it would be nice to have a way to capture the exception in the 'except' block. |
18:21:46 | reactormonk | lesshaste, do you use asm frequently? |
18:21:51 | lesshaste | reactormonk, never |
18:21:58 | dom96 | like: except varName: EOS : |
18:21:59 | lesshaste | reactormonk, I just want to use scientific libraries |
18:22:01 | dom96 | or something, but that looks weird |
18:22:44 | reactormonk | lesshaste, yup, then wrap them and you should be good. c2nim the header files and you should be able to use them. However, c2nim isn't perfect, so you will have to remove some stuff from the header file and port it yourself |
18:23:15 | reactormonk | there's some pragma pushing you can do to reduce the verbosity of the wrapper file, lemme see... |
18:23:31 | lesshaste | ok thanks |
18:23:37 | lesshaste | this may be beyond me at the moment |
18:23:38 | lesshaste | but thanks |
18:24:10 | dom96 | lesshaste: what kind of scientific computing do you do? |
18:24:23 | lesshaste | dom96, mostly uses of linear algebra libraries |
18:24:32 | lesshaste | calculating eigenvalues, rank etc. |
18:24:53 | reactormonk | lesshaste, you can push and pop pragmas if you want to apply them to multiple procs |
18:25:01 | dom96 | lesshaste: perhaps this would be of use to you then: https://bitbucket.org/BitPuffin/linagl |
18:25:16 | lesshaste | dom96, looks good! |
18:25:22 | lesshaste | I hope they are not reimplementing it all! |
18:25:30 | lesshaste | the amount of reimplementation of standard libraries drives me spare |
18:26:08 | dom96 | although IIRC there may be some problems with that library due to compiler bugs :\ |
18:26:21 | dom96 | EXetoC: Actually, it looks like I can just set currException |
18:26:44 | dom96 | EXetoC: if it was exported D: |
18:28:40 | * | BitPuffin quit (Ping timeout: 265 seconds) |
18:28:42 | * | nande joined #nimrod |
18:30:28 | EXetoC | dom96: so, set it in the beginning of the block, and then unset at the end? if it's even that simple |
18:31:17 | dom96 | yea |
18:32:50 | * | OrionPK quit (Remote host closed the connection) |
18:40:11 | * | OrionPK joined #nimrod |
18:42:36 | * | Demos joined #nimrod |
18:48:18 | * | angus joined #nimrod |
18:48:26 | angus | hello |
18:49:36 | dom96 | hi angus |
18:49:38 | angus | how can I initialize an array with an index or elements of range type? |
18:50:01 | angus | type |
18:50:01 | angus | RangeA = range[1..3] |
18:50:01 | angus | RangeB = range[1..10] |
18:50:01 | angus | const Arr: array[RangeA, RangeB] = [1, 2, 3] |
18:50:23 | angus | I get: |
18:50:42 | reactormonk | angus, well, you're not giving it an array of ranges |
18:50:58 | angus | well I can't paste the error. |
18:51:22 | angus | reactormonk: ? |
18:51:30 | reactormonk | angus, I guess it's complaining about array of ints vs. array of ranges? |
18:51:42 | angus | I give it an array of integers inside the range |
18:52:00 | angus | reactormonk: yes. |
18:52:14 | angus | Error: type mismatch: got (Array constructor[0..2, int]) but expected 'array[1..3, RangeB]' |
18:52:29 | angus | I can't also cast it |
18:52:29 | dom96 | [1.RangeB, 2, 3] |
18:52:31 | fowl | lesshaste, what library do you need wrapped? i'll take a look at it and see if it is easily doable wiht c2nim |
18:52:43 | reactormonk | dom96, ah cool |
18:52:43 | EXetoC | implicit conversion only works for the elements after the first one, and the first element decides the type |
18:52:51 | angus | aha! |
18:52:56 | EXetoC | and as such you can do things like [1i32, 2, 3] |
18:53:01 | reactormonk | thought that wasn't possible ^^ |
18:53:13 | reactormonk | is the range type checked at runtime? |
18:53:36 | EXetoC | it might perform the check at compile time in some cases |
18:53:41 | dom96 | IMO angus' code should just work |
18:53:43 | angus | dom96: great, it works! |
18:53:48 | angus | thanks |
18:53:51 | dom96 | without the need for 'RangeB' |
18:53:52 | reactormonk | dom96, well, that would be return type overload |
18:54:03 | dom96 | but Araq says it's tricky |
18:54:07 | dom96 | so this is necessary for now. |
18:54:12 | dom96 | angus: np |
18:54:32 | lesshaste | fowl, thanks! basically lapack |
18:54:46 | lesshaste | http://www.netlib.org/lapack/ |
18:54:54 | reactormonk | dom96, didn't know about the ranges as types O.o |
18:55:19 | dom96 | reactormonk: ranges are indeed types :P |
18:55:23 | EXetoC | Natural and Positive in system are good examples |
18:56:05 | EXetoC | and maybe those should be generic, but with int by default. doesn't work yet though |
18:56:26 | reactormonk | EXetoC, then we get into typeclasses |
18:57:10 | EXetoC | yes |
18:59:04 | angus | I think I'm giving up on range types for now |
18:59:25 | dom96 | angus: how come? |
18:59:38 | angus | I thought having a range parameter would help to check argument values automatically |
19:00:02 | angus | but it forces me to cast the arguments to the range type |
19:00:15 | * | BitPuffin joined #nimrod |
19:00:18 | EXetoC | not just the first? |
19:00:18 | angus | if I have proc x(a: RangeType) |
19:00:39 | angus | I can't call it as x(1). I have to write it as x(RangeType(1)) |
19:00:44 | EXetoC | I've never needed to explicitly cast, except when dealing with tuples |
19:00:55 | dom96 | sounds like a bug |
19:01:13 | fowl | that is most definitely a regression or something |
19:01:22 | EXetoC | do the underlying types match? |
19:01:45 | angus | where can I paste? |
19:01:50 | angus | pastebin? |
19:01:57 | EXetoC | gist? |
19:02:13 | EXetoC | some people don't like pastebin |
19:02:25 | dom96 | gist supports nimrod |
19:05:27 | angus | ok, here it is: https://gist.github.com/anonymous/998daa3b3c150dad2915 |
19:05:48 | angus | problem is in the object constructor, not the proc invokation as I mistakenly thought |
19:05:52 | Araq | reactormonk: nimrod's "asm" is mapped to C's "asm" section, no need for 2 asms or something |
19:06:10 | angus | Error: type mismatch: got (int, TMonthRange, TDayRage) |
19:06:16 | angus | why? |
19:07:42 | Araq | because object constructors look like this: |
19:07:54 | Araq | TDate(year: year, month: m, day: d) |
19:08:07 | Araq | btw hi angus welcome |
19:08:08 | lesshaste | fowl, maybe someone is already working on lapack? |
19:08:19 | lesshaste | fowl, given the linear algebra link someone pasted before |
19:08:27 | angus | Araq: same error, just with the labels |
19:08:31 | lesshaste | https://bitbucket.org/BitPuffin/linagl |
19:09:00 | angus | Araq: wait! no |
19:09:08 | angus | that works. I was using "=" |
19:10:00 | angus | Araq: thanks :) |
19:11:20 | * | ehaliewicz joined #nimrod |
19:12:08 | * | Trimsty joined #nimrod |
19:14:32 | reactormonk | lesshaste, ^ I stand corrected |
19:15:04 | lesshaste | reactormonk, sorry.. about what? |
19:15:09 | reactormonk | lesshaste, asm |
19:15:21 | lesshaste | reactormonk, oh I see :) |
19:15:29 | * | Trimsty quit (Client Quit) |
19:19:33 | * | boydgreenfield quit (Read error: Connection reset by peer) |
19:19:56 | * | boydgreenfield joined #nimrod |
19:21:21 | * | boydgreenfield quit (Read error: Connection reset by peer) |
19:21:53 | * | BitPuffin quit (Ping timeout: 264 seconds) |
19:22:14 | * | boydgreenfield joined #nimrod |
19:22:58 | Varriount | dom96: Is there a way to schedule a repeating callback yet? or a timed callback? |
19:24:00 | * | boydgreenfield quit (Read error: Connection reset by peer) |
19:24:54 | * | boydgreenfield joined #nimrod |
19:28:22 | fowl | lesshaste, lapacke.h looks like it should translate without much modification |
19:28:31 | lesshaste | fowl, great! |
19:28:46 | fowl | freaking big though, mine is > 16k lines |
19:28:59 | lesshaste | fowl, yes it's a very important library |
19:36:03 | * | BitPuffin joined #nimrod |
19:39:03 | * | Jesin quit (Ping timeout: 250 seconds) |
19:39:48 | * | menscrem quit (Ping timeout: 240 seconds) |
19:42:09 | * | nande quit (Ping timeout: 245 seconds) |
19:45:40 | dom96 | Varriount: no |
19:46:04 | * | Matthias247 joined #nimrod |
19:49:59 | * | Jesin joined #nimrod |
19:52:10 | Araq | hi Matthias247 wb |
19:52:20 | Matthias247 | hi |
19:55:09 | * | BitPuffin quit (Ping timeout: 240 seconds) |
19:59:55 | Araq | milosn: var foo: MyObject |
20:00:09 | Araq | var a = foo.toAny() |
20:00:28 | Araq | a["fieldName"] = 14.toAny |
20:01:33 | Araq | for name, val in a: echo name |
20:03:06 | milosn | Araq: thanks, i havent got to that part yet ... :) |
20:03:26 | milosn | ill note it down as a comment in the code, so i dont have to ask again ;) |
20:03:57 | Araq | oh yeah, get rid of your DomainBase OO crap |
20:04:11 | Araq | it won't help you |
20:04:25 | milosn | yes, slowely i am coming to realise that myself |
20:04:35 | milosn | it just wont "bend" that way |
20:05:30 | Araq | you should do it entirely differently |
20:05:46 | milosn | like? i am open to suggestions :) |
20:05:55 | Araq | we already have an SQL parser |
20:06:17 | milosn | you know better how nimrod will "bend" ... but i am not making another ORM-ish DSL |
20:06:20 | milosn | :) |
20:06:26 | * | milosn dont belive in DSL that does SQL |
20:06:37 | Araq | you should write a tool that connects to a database and asks it for the table descriptions |
20:06:52 | * | Jehan_ quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
20:06:54 | milosn | hmm ok, and than? |
20:07:09 | milosn | thats what my "mygenbase" does, and generates .nim base files |
20:07:10 | Araq | this tool then parses the SQL and generates *type-safe* nimrod wrapper glue |
20:07:52 | Araq | and then all you need to do is to ensure the tool works decently with nimrod's staticExec |
20:08:06 | Araq | you could instead write it all as macro |
20:08:43 | Araq | but I think the macro VM is still not up for this task |
20:09:14 | Araq | plus people don't really want to recompile the ORM tool whenever they recompile their application |
20:09:36 | milosn | hmmm thats cool, i could do that in an afternoon and have basic AR ORM in place (or couople fo afternnons :P) ... but we lack the most fundamental bit of AR style ORMs ... you cant extend your DB objects |
20:09:45 | milosn | add useful procs etc. |
20:09:57 | * | boydgreenfield quit (Ping timeout: 240 seconds) |
20:10:03 | milosn | Araq: other option is ... DSL for SQL, i dont wanna do that :) |
20:10:19 | Araq | well I agree |
20:10:25 | Araq | SQL already is a DSL |
20:10:49 | Araq | the major problem is that it is not type-safe |
20:11:01 | * | boydgreenfield joined #nimrod |
20:11:02 | Araq | when you use sql"foo bar" in Nimrod |
20:11:13 | Araq | and that sucks |
20:11:35 | * | boydgreenfield quit (Client Quit) |
20:11:39 | milosn | hmmm |
20:12:08 | Araq | perhaps you should generate a domSql proc that checks the SQL at compile-time |
20:12:24 | Araq | er, I mean a macro |
20:13:10 | Araq | well it depends on what you're after |
20:13:22 | Araq | you said "extend the DB objects" |
20:13:33 | Araq | I said "type safety" ;-) |
20:13:56 | milosn | something easy to use :) ... and get the job done (imaginary job, i dont do anything in nimrod yet) :D |
20:14:07 | milosn | btw what does this tell me: test.nim(15, 10) Error: expression cannot be casted to TDomain |
20:14:28 | Araq | don't use 'cast' |
20:14:39 | milosn | use conversion? |
20:14:44 | Araq | yes |
20:15:00 | Araq | and if type conversion doesn't work, you're doing it wrong |
20:15:12 | milosn | ive tried, i cant do a single one ... is there some pragma or something which i am missing? |
20:15:27 | * | milosn looks at the manual again |
20:16:46 | milosn | oh spoke to soon ... my cast: |
20:16:47 | milosn | var base: TBase_domains = initTBase_domains() |
20:16:48 | milosn | var d = TDomain(base) |
20:16:49 | * | lesshaste quit (Quit: Leaving) |
20:16:52 | milosn | that worked |
20:16:55 | milosn | err conversion |
20:16:58 | milosn | not cast |
20:17:10 | milosn | let me see if test code works when i run it :P |
20:17:37 | milosn | Araq: if i manage to "bend" it the way i want it ... you are gonna hate me dude |
20:17:41 | milosn | but thats life :P |
20:18:08 | Araq | yes. don't worry. I hate everything anyway. |
20:18:16 | milosn | :) |
20:18:37 | Araq | I'd focus on type safety and on generating prepared statments though :P |
20:19:00 | Araq | these are clear goals and you end up with something better than the db_* modules |
20:19:46 | Araq | the alternative is to go after buzzwords and people will continue to use the db_* modules because they work. :P |
20:20:12 | milosn | :D |
20:20:47 | milosn | you got lucky ... conversion compiles, but dont actualy work |
20:21:57 | Araq | for inheritance you should really work with 'ref' btw |
20:22:07 | Araq | everything else is tricky |
20:22:27 | Araq | (plus there is still some compiler bug lurking in there...) |
20:28:08 | njoejoe | var buckets: array[0..9, string] gives "ambiguous identifier: 'string' -- use a qualifier" how to do it? |
20:28:26 | Araq | system.string |
20:28:53 | njoejoe | thank you |
20:33:49 | * | boydgreenfield joined #nimrod |
20:43:54 | njoejoe | is there a way to tell array to initialize the strings to ""? if i buf[x] &= "appending" i get sigsegv unless I first loop through the array and initialize the strings. also, why system.string instead of plain "string" as type? |
20:46:41 | EXetoC | just 'string' should be enough as long as it hasn't been exported in one of the imported modules |
20:47:41 | fowl | njoejoe, you defined string? |
20:48:17 | njoejoe | fowl: no. perhaps because i'm using 0.9.5 version of nimrod? |
20:48:21 | EXetoC | njoejoe: there's no such shortcut I think, but add (&=) will basically behave like safeAdd eventually, where a nil target will be assigned the content of the second argument rather than resulting in a crash |
20:48:45 | fowl | njoejoe, "ambiguous identifier: 'string' -- use a qualifier" means there is another string defined |
20:49:17 | EXetoC | such bugs might still exist |
20:49:59 | fowl | njoejoe, proc init (arr: var openarray[string]) = for idx in 0 .. high(arr): arr[idx] = "" |
20:50:17 | njoejoe | fowl: my entire program just consisted of the line: var buckets: array[0..9, string] so perhaps something with 0.9.5 |
20:50:22 | EXetoC | it's not required at all times anyway. that'd break about a million things |
20:51:06 | fowl | njoejoe, i cant reproduce |
20:51:10 | EXetoC | njoejoe: I just compiled that compile. no errors |
20:51:47 | EXetoC | so no imports? |
20:52:35 | njoejoe | OMG. my testfile was called "string.nim" i think that was the problem... oops. |
20:55:05 | Araq | yeah a common gotcha |
20:55:26 | Araq | but I don't know what can be done about it, explicit "module foo" lines are meh |
20:56:50 | dom96 | why can't the compiler disambiguate that? |
20:57:07 | Araq | oh it can easily |
20:57:14 | Araq | but I can't do everything |
20:57:34 | Araq | and disambiguation only is about overload resolution currently |
20:57:44 | dom96 | then why the mention of explicit "module foo" lines |
20:58:07 | njoejoe | I don't think it's a problem. i'm pretty sure i'll never do it again. |
20:58:14 | Araq | because it's not always possible to disambiguate |
20:58:44 | Araq | njoejoe: yeah but pretty much every newbie stumbles over that |
20:58:52 | Araq | but oh well |
21:01:33 | Araq | oh btw ... I am now misusing my power to tell you guys: Foxit Reader made me install the Yahoo Search Bar accidentically. |
21:01:52 | Araq | and that's it. I'll never use it again. |
21:06:13 | Araq | that thing is an impertinence sondergleichen |
21:06:41 | dom96 | You're right. We should put that in Nimrod's installer. |
21:06:45 | dom96 | To make some bucks. |
21:06:46 | Araq | eine unglaubliche Unverschämtheit |
21:08:26 | boydgreenfield | hi all, quick question – is anyone using the memfiles module? And if so, to actually create mmap files, or just to write them? I get an EOS / bad file descriptor error whenever I try to create a new mmap file, but perhaps I’m misunderstanding the usage. |
21:11:43 | Araq | boydgreenfield: the compiler itself uses it but only for reading |
21:11:54 | Araq | maybe writing is broken :-/ |
21:12:22 | boydgreenfield | Ah ha. Well, if this usage is correct, then I think it probably is :) :mm = memfiles.open("/tmp/test2.mmap", mode = fmReadWrite) |
21:13:44 | Araq | looks good yeah |
21:13:59 | Araq | please fix it and make a pr |
21:14:26 | boydgreenfield | Yep… looking into it now. |
21:18:17 | boydgreenfield | Ok. Sorry it works fine. I made the mistake of using `mappedSize` instead of `newFileSize`. |
21:18:29 | reactormonk | boydgreenfield, o/ |
21:18:45 | boydgreenfield | I.e., mm = memfiles.open("/tmp/test2.mmap", mode = fmReadWrite, mappedSize = 1000) instead of mm = memfiles.open("/tmp/test2.mmap", mode = fmReadWrite, newFileSize = 1000) |
21:18:49 | boydgreenfield | Yes. Embarassing. Sorry. |
21:19:01 | reactormonk | boydgreenfield, write a comment in the documentation of the method |
21:19:08 | reactormonk | you probably won't be the last one |
21:19:59 | fowl | aye |
21:20:02 | fowl | give the module some examples |
21:20:22 | reactormonk | is it just me or should mappedsize and newfilesize the same in case of writing? |
21:20:48 | reactormonk | or mappedsize and newfilesize are for read/write, and not to be used together? |
21:21:14 | Araq | they are orthogonal concepts if you ask me |
21:21:49 | reactormonk | Araq, in memory, the other on the disk? |
21:22:05 | Araq | yes |
21:22:16 | reactormonk | does the size in memory matter when you're writing? |
21:22:55 | boydgreenfield | To confirm: the proper branch to submit a PR to is `devel` yes? |
21:23:06 | Araq | depends, you can write past its end to append to the file |
21:23:08 | * | flaviu joined #nimrod |
21:23:21 | Araq | boydgreenfield: right |
21:23:22 | reactormonk | boydgreenfield, yup |
21:23:32 | reactormonk | Araq, ok, point taken |
21:25:19 | reactormonk | Araq, found a downside to my new $ for floats. 5.0 is "5". |
21:26:05 | Araq | reactormonk: patch it afterwards |
21:26:20 | Araq | append ".0" when necessary |
21:26:23 | reactormonk | not sure what's the right way to do it |
21:26:34 | Araq | it is, trust me |
21:26:47 | fowl | lol |
21:26:54 | fowl | reactormonk, lets just see how ruby does it |
21:27:16 | reactormonk | fowl, no idea anymore where the code is :-/ |
21:27:29 | * | Jehan_ joined #nimrod |
21:27:36 | flaviu | Is there a way to take a pointer and a length and call it a string? |
21:27:59 | Araq | only with a copy, flaviu |
21:28:03 | reactormonk | flaviu, a cstring is just an array IIRC, so you should be able to cast it to one |
21:28:06 | fowl | reactormonk, lol, from mruby: > 5.00001 |
21:28:07 | fowl | => 5.00000999999999 |
21:28:40 | fowl | reactormonk, mruby has less code, i'll look there |
21:29:21 | reactormonk | fowl, try 5.0 |
21:29:42 | reactormonk | ... that's just float. |
21:30:23 | fowl | its "5.0" |
21:31:37 | Jehan_ | Umm, IEEE 754 fp numbers can't represent decimal fractions accurately? That's nothing new. |
21:32:17 | Araq | Jehan_: what's the best way to implement a barrier? I'm using a counter + a condition variable |
21:32:20 | reactormonk | fowl, huh |
21:32:24 | fowl | reactormonk, https://github.com/mruby/mruby/blob/master/src/numeric.c#L111 |
21:33:00 | reactormonk | fowl, hmm |
21:33:09 | Jehan_ | Araq: Umm. Second best is to handcode it in assembly. :) |
21:33:11 | fowl | huge function |
21:33:11 | reactormonk | just copy that one? |
21:33:15 | Jehan_ | Best is not to use one. :) |
21:33:52 | Jehan_ | Barrier usually means n-1 threads come to a halt => poor CPU utilization. |
21:34:00 | Jehan_ | Also, thundering herd problem. |
21:34:45 | Araq | well I need it for correctness and last I checked correctness is sometimes more important than speed. |
21:35:45 | fowl | reactormonk, yea but it doesnt look fun. give me about a week lol |
21:36:59 | Jehan_ | I'll explain in a minute why I wasn't being facetious (or only partly). For now: |
21:37:20 | Jehan_ | A condition variable is an acceptable temporary hack to provide the functionality. |
21:37:39 | Jehan_ | It's likely not to be very efficient, though. |
21:38:42 | Jehan_ | A semaphore-based solution is likely the better choice. |
21:39:03 | Jehan_ | But we're now running into various implementation-specific questions. |
21:39:39 | boydgreenfield | reactormonk / Araq: Comment on memfiles mappedSize / newFileSize. So there is an issue with them being orthogonal, because it following use case fails: mm = open(“/tmp/test.mmap”, newFileSize= 1024, mappedSize = -1) |
21:39:52 | flaviu | Araq: Sumatra PDF is small and super fast |
21:40:00 | Jehan_ | First of all, some pthread implementations support only a subset of semaphore functionality. |
21:40:26 | Araq | meh semaphores |
21:40:39 | Araq | it's been years since I last used one |
21:40:40 | boydgreenfield | (sorry bumped enter), which means that you can’t really use open() in readWrite mode without first checking if the file exists. Araq, from your perspective is this the desired behavior and one should just have a higher-level wrapper around the functionality? I’ll write up a longer docstring either way. |
21:41:28 | Jehan_ | So you may have to write something different or write a fallback implementation. |
21:41:32 | Araq | boydgreenfield: I think this behaviour is fine, but if it's cheap to avoid, go for it |
21:41:48 | Araq | I only use locks or condition variables |
21:42:01 | Araq | or cas or atomic stuff |
21:42:07 | Jehan_ | That's extremely portable, but not always sufficient. |
21:42:10 | boydgreenfield | Araq: That’s fine, I’ll just document that one shouldn’t expect that to work. |
21:42:51 | Jehan_ | In general: If you don't mind the speed hit from barriers, you may as well just have a thread wait for the remaining ones. |
21:43:10 | Jehan_ | It's more likely to produce correct code (that's another problem with barriers). |
21:43:47 | Jehan_ | If you do mind, what you actually want is the "sync results" and "wait for results to be complete" be separate steps. |
21:44:47 | Jehan_ | So that the system doesn't grind to a halt each time you use a barrier and one thread is lagging a bit behind. |
21:45:44 | Jehan_ | In general, that approach leads to a data flow architecture, though. |
21:46:14 | Jehan_ | Because it's still one of the best ways to reason about the coordination of multiple threads in non-trivial situations. |
21:46:59 | Jehan_ | If you just want to provide a basic barrier implementation, though, yeah, just use mutexes and condition variables. At least that's what I always did. :) |
21:47:50 | Jehan_ | It's functional, and the implementation is robust without a number of special cases to consider and test. |
21:47:56 | Araq | well I implemented my own "FastCondVar". wasn't faster at all, but introduced nice crashes |
21:48:20 | Jehan_ | Heh. Been there, done that. :) |
21:48:52 | Araq | was on windows though with my barely sufficient timing methods |
21:48:54 | Jehan_ | The problem with rolling your own condition variables is that it's really hard to implement blocking efficiently and portably. |
21:49:18 | Araq | yeah but for that I uses the OS's cond var as a fallback |
21:49:23 | Araq | *used |
21:49:47 | Jehan_ | For example, on POSIX it generally means that you're playing around with signals, meaning you're eating up a signal slot, plus the usual adventures in sigsuspend()/sigwait()/etc. semantics. |
21:50:12 | Araq | I pretend signals don't exist |
21:50:27 | Jehan_ | They're unfortunately necessary to do certain things at all. |
21:50:49 | Jehan_ | And wouldn't be as much of a problem if there were more signal numbers available (portably). |
21:51:05 | Araq | I hate all this Unix crap. It's incredibly bug prone. |
21:51:54 | Jehan_ | I could say the same about some of the Windows stuff. :) Even though I don't share the usual Unix attitude about looking down on Windows. |
21:52:04 | njoejoe | Araq: what's your OS of choice? |
21:52:32 | Jehan_ | Windows does some stuff amazingly well. Other things not so much. But that's true of all OSes. |
21:52:42 | Araq | njoejoe: Haiku. (Political answer) |
21:53:08 | njoejoe | :-) nimos FTW! |
21:54:12 | Jehan_ | But yeah, wait-while-stopping-the-world is a functionality that I wouldn't prioritize for wasting speedup efforts on. |
21:54:13 | flaviu | Jehan_: The thing that windows does the best of all OSes is being compatible with windows |
21:54:33 | Jehan_ | Chances are most of the system is going to sit idle, anyway, so who cares about speed? |
21:55:32 | Araq | Jehan_: I don't really want to discuss this again, but |
21:55:40 | Jehan_ | Heh. :) |
21:55:42 | Araq | let foo = getFuture(input) |
21:55:54 | Araq | only works when 'input' is on the heap |
21:57:07 | Araq | and that's something Groovy's dataflow variables don't have to consider |
21:57:25 | Araq | but it surely matters *a lot* for Nimrod |
21:58:54 | Jehan_ | True, but not all forms of dataflow have to involve futures. |
21:59:27 | Jehan_ | Barriers are a pretty low-level operation regardless. |
21:59:55 | Araq | Barriers keep the stack frame from disappearing :P |
22:02:05 | Araq | also iirc barriers are really cheap on a GPU |
22:03:35 | Jehan_ | The problem with barriers is more that you're turning an N-core system into a 1-core system for a bit. :) |
22:03:55 | Jehan_ | And then Amdahl's law hurts you. |
22:06:23 | NimBot | Araq/Nimrod devel d043854 Araq [+0 ±7 -0]: implemented builtin noncopying slice |
22:06:23 | NimBot | Araq/Nimrod devel a11ae92 Araq [+0 ±2 -0]: fixes #1140 |
22:06:23 | NimBot | Araq/Nimrod devel 4055fd4 Araq [+0 ±1 -0]: some additions to winlean |
22:06:23 | NimBot | Araq/Nimrod devel fe690a2 Araq [+1 ±0 -0]: added test case for bug #1140 |
22:06:23 | NimBot | 1 more commits. |
22:07:01 | Araq | OrionPK: here you go. Finally I fixed it. |
22:14:43 | Araq | Jehan_: what do you mean "dataflow without futures"? |
22:15:21 | Jehan_ | Well, that dataflow is a concept that's not necessarily tied to specific programming language implementations. |
22:15:30 | Jehan_ | As a very basic example, think petri nets. |
22:16:16 | Araq | sure |
22:17:01 | Jehan_ | Futures are being used a lot these days because they have many attractive features in addition. |
22:17:50 | NimBot | Araq/Nimrod devel 77d5ab1 Araq [+0 ±2 -0]: bootstraps works again; get rid of compile-time 'rand' (too weird) |
22:18:21 | * | reloc0 quit (Read error: Operation timed out) |
22:18:47 | Jehan_ | Barriers are generally more interesting for distributed systems, where this kind of synchronization is genuinely hard. |
22:19:37 | * | reloc0 joined #nimrod |
22:19:51 | Jehan_ | For shared memory systems, I'd recommend to have a look at SNZIs (scalable non-zero indicators). These aren't barriers, but have related semantics that are also often useful. |
22:42:35 | * | xenagi joined #nimrod |
23:00:38 | * | nande joined #nimrod |
23:01:27 | OrionPK | Araq cool, I will test out the full templates lib later tonight |
23:02:25 | boydgreenfield | Araq / reactormonk: Another question realted to memfiles. It appears that creating a new mmap-backed file only has the group read and execute permissions set. I’m looking through the system open() source code, and believe this is set here https://github.com/Araq/Nimrod/blob/devel/lib/posix/posix.nim#L1799. But at least this guide indicates that a mode constant has to be specified if using the O_CREAT flag, which |
23:02:25 | boydgreenfield | I don’t see being done http://linux.die.net/man/2/open. Can anyone w/ more POSIX experience comment? It appears to me that the file permission flags aren’t being set properly becuase the call to open(filehandle, flags) should really be open(filehandle, flags, mode) since flags has O_CREAT set. Correct? |
23:07:09 | * | milosn quit (Ping timeout: 245 seconds) |
23:10:01 | * | Matthias247 quit (Read error: Connection reset by peer) |
23:11:57 | Jehan_ | Araq: https://gist.github.com/rbehrends/2783e808550b1f11ae19 |
23:12:10 | Jehan_ | Some barrier code that doesn't suck entirely. :) |
23:14:46 | OrionPK | compiler/semfold.nim(410, 5) Error: undeclared identifier: 'mRand' ? |
23:15:42 | dom96 | yep, he broke the build. |
23:20:02 | reactormonk | boydgreenfield, int open(const char *path, int oflag, ...); according to the manpage, it seems like the wrapper is incomplete |
23:20:05 | reactormonk | boydgreenfield, just add your own. |
23:20:46 | reactormonk | boydgreenfield, oh wait, it's got the varargs pragma, so it should as you expect it to with posix.open(filename, flags, mode) |
23:20:48 | fowl | reactormonk, no, that is a varargs function |
23:22:55 | dom96 | good night |
23:23:27 | njoejoe | good night dom96 |
23:25:11 | * | milieu joined #nimrod |
23:33:31 | boydgreenfield | reactormonk: Ah. Just picking this up and wasn’t familiar with the .varaargs. proc. I’ve patched it locally and will submit a PR for the memfiles module to do the same (doesn’t seem very useful to have the default behavior create a file you can’t re-open). |
23:36:38 | * | Skrylar joined #nimrod |
23:49:40 | * | Jesin quit (Quit: Leaving) |
23:59:31 | * | darkf joined #nimrod |