00:15:47 | * | [CBR]Unspoken quit (Ping timeout: 256 seconds) |
00:35:42 | * | [CBR]Unspoken joined #nim |
00:44:56 | * | renesac quit (Ping timeout: 252 seconds) |
00:45:24 | * | brson quit (Ping timeout: 264 seconds) |
00:47:02 | * | brson joined #nim |
00:55:43 | * | [CBR]Unspoken quit (Ping timeout: 252 seconds) |
00:57:26 | * | renesac joined #nim |
01:11:37 | * | [CBR]Unspoken joined #nim |
01:14:06 | * | Demos joined #nim |
01:18:17 | * | [CBR]Unspoken quit (Ping timeout: 240 seconds) |
01:18:59 | * | Demos quit (Ping timeout: 265 seconds) |
01:21:11 | * | Jesin joined #nim |
01:21:16 | * | [CBR]Unspoken joined #nim |
01:21:23 | * | rinukkusu quit (Ping timeout: 250 seconds) |
01:24:17 | * | rinukkusu joined #nim |
01:28:52 | * | vasher_ joined #nim |
01:31:27 | renesac | where I find a list of things about the plataform that the compiler provides? |
01:31:35 | renesac | like, what cpu is it |
01:31:54 | renesac | to acess by "when" in a nim file |
01:33:16 | renesac | what OS is it, etc |
01:58:07 | EXetoC | renesac: when defined(<os>) |
01:58:14 | * | drewsrem quit (Quit: Leaving) |
01:58:24 | renesac | where is a list I can refer to? |
01:58:46 | renesac | a table, something like that |
01:59:07 | * | groungch joined #nim |
01:59:20 | * | groungch left #nim (#nim) |
01:59:48 | EXetoC | I've only seen one in compiler/platform.nim (line ~40, const named OS) |
02:00:08 | EXetoC | Linux, Windows, MacOS, MacOSX, FreeBSD... |
02:02:11 | renesac | right, it seems that it is all in that file |
02:06:06 | renesac | it should be documented outside it.. |
02:06:36 | renesac | aaand, I discovered I can simply do "clong.sizeof" |
02:06:52 | EXetoC | yep |
02:12:17 | * | brson quit (Quit: leaving) |
02:35:58 | * | MatrixBridge quit (Remote host closed the connection) |
02:36:06 | * | MatrixBridge joined #nim |
02:40:01 | * | vendethiel joined #nim |
02:41:39 | onionhammer | apense the websocket implementation works with ws:// only, not secure websockets |
02:41:44 | onionhammer | oop |
02:58:19 | * | perturbation joined #nim |
03:00:10 | perturbation | hey all - bit of a weird question. Is it possible to check for presence of a module (so that you can provide what JS folks would call a 'polyfill') if a dependency is not present? |
03:00:19 | perturbation | i.e. |
03:00:29 | perturbation | when definedInImportPath(foo): |
03:00:32 | perturbation | import foo |
03:19:30 | * | darkf joined #nim |
03:24:05 | perturbation | hmmm... I think I can use compiler/option.nim's findModule() proc |
03:24:11 | perturbation | but I have to play around with it some more |
03:24:24 | * | perturbation quit (Quit: Leaving) |
03:38:52 | * | vasher_ quit (Quit: Connection closed for inactivity) |
03:44:57 | * | vendethiel quit (Ping timeout: 265 seconds) |
03:45:06 | * | eventualbuddha quit (Read error: Connection reset by peer) |
03:45:53 | * | clone1018 quit (Ping timeout: 252 seconds) |
03:46:15 | * | TylerE quit (Ping timeout: 246 seconds) |
03:46:17 | * | pmbauer quit (Ping timeout: 252 seconds) |
03:46:17 | * | mikolalysenko quit (Ping timeout: 252 seconds) |
03:47:18 | * | DecoPerson quit (Ping timeout: 246 seconds) |
03:48:06 | * | vendethiel joined #nim |
03:54:45 | * | pmbauer joined #nim |
03:57:56 | * | mikolalysenko joined #nim |
03:59:22 | * | clone1018 joined #nim |
04:01:28 | * | BitPuffin|osx joined #nim |
04:02:02 | * | TylerE joined #nim |
04:10:21 | * | eventualbuddha joined #nim |
04:10:50 | * | vendethiel quit (Ping timeout: 256 seconds) |
04:13:53 | * | strcmp1 quit (Quit: Leaving) |
04:15:36 | * | pregressive quit (Remote host closed the connection) |
04:18:55 | * | DecoPerson joined #nim |
04:22:56 | renesac | EXetoC: done: https://github.com/nim-lang/Nim/wiki/Consts-defined-by-the-compiler |
04:23:31 | renesac | those lists probably should be auto-generated and included in the documentation, but for now they are there |
04:31:49 | * | rgv151 joined #nim |
04:35:35 | * | Jesin quit (Quit: Leaving) |
05:11:52 | * | elbow_jason joined #nim |
05:20:10 | * | luke joined #nim |
05:20:12 | * | luke is now known as Guest23028 |
05:21:15 | Guest23028 | is there a way to memset an int array in nim? |
05:22:09 | * | BitPuffin|osx quit (Ping timeout: 246 seconds) |
05:28:57 | Guest23028 | alternatively, say you have an array that has to be set back to 0 very often, what is the fastest way to do this? |
05:30:56 | fowl | Guest23028, system.zeromem() |
05:33:12 | Guest23028 | cheers fowl |
05:36:39 | * | pregressive joined #nim |
05:53:45 | * | pregressive quit (Remote host closed the connection) |
06:11:44 | * | jszymanski joined #nim |
06:13:20 | * | pregressive joined #nim |
06:17:17 | * | vendethiel joined #nim |
06:27:02 | * | renesac quit (Ping timeout: 252 seconds) |
06:30:12 | * | pregressive quit (Remote host closed the connection) |
06:39:17 | * | renesac joined #nim |
06:41:47 | * | vendethiel quit (Ping timeout: 240 seconds) |
06:52:00 | * | Demos joined #nim |
06:56:21 | * | Demos quit (Ping timeout: 255 seconds) |
06:56:43 | * | EXetoC quit (Ping timeout: 246 seconds) |
06:59:29 | * | xet7 quit (Quit: Leaving) |
07:01:16 | * | vendethiel joined #nim |
07:11:21 | * | cazov quit (Ping timeout: 246 seconds) |
07:14:34 | * | cazov joined #nim |
07:17:03 | Guest23028 | so, integer division of int64/int64, not allowed to? is this not supported? |
07:17:24 | Guest23028 | l.nim(34, 20) Error: type mismatch: got (int64, int) |
07:17:25 | Guest23028 | but expected one of: |
07:17:25 | Guest23028 | system./(x: int, y: int) |
07:17:25 | Guest23028 | system./(x: float32, y: float32) |
07:17:25 | Guest23028 | system./(x: float, y: float) |
07:20:34 | Guest23028 | ah sorry. 'div' is used. didn't realise / always returns float |
07:20:58 | * | darkf quit (Read error: Connection reset by peer) |
07:21:32 | * | vendethiel- joined #nim |
07:21:33 | * | vendethiel quit (Ping timeout: 255 seconds) |
07:21:57 | * | darkf joined #nim |
07:29:36 | * | keypusher quit (Remote host closed the connection) |
07:30:02 | * | key_ joined #nim |
07:39:38 | Guest23028 | so hey, how does the binary & operator work on ints in nim? I wanna see if a&b is true but I cannot & two int's |
07:43:10 | * | vendethiel- quit (Ping timeout: 248 seconds) |
07:44:32 | Guest23028 | it seems like 'and' works but then how do I &= a value? |
07:47:11 | * | vendethiel joined #nim |
07:56:31 | r-ku | Araq | [17:42:11] r-ku: you can have a fastcall call that calls a cdecl function |
07:56:37 | r-ku | still need to tell c compiler that fastcall is to be used |
08:08:01 | * | vendethiel quit (Ping timeout: 244 seconds) |
08:08:17 | Guest23028 | hey, does anyone mind giving me a little hand? I don't get these 'and' and 'or' and & etc rules. I've looked around and it doesn't really say from what i've seen |
08:09:02 | Guest23028 | this gets out of bounds 'arr[n shr 3] or int8(1 shl (n mod 8))' but i can print both sides of it fine without going out of bounds. any idea? am i using or completely wrong? |
08:13:35 | * | coffeepot joined #nim |
08:18:24 | Guest23028 | oh! uint8 operations are not available without import the module? is this why i cant go uint8 or int? |
08:25:16 | * | Trustable joined #nim |
08:31:01 | * | Guest23028 quit (Quit: Leaving) |
08:31:25 | * | luke joined #nim |
08:31:49 | * | luke is now known as Guest86655 |
08:35:40 | Guest86655 | Hey people, so i'm trying to write a segmented sieve of Eratosthenes in Nim, I've got the algorithm working fine however its slow! I'm very new to Nim and would like some performance pointers. If anyone is willing to have a look, i'd much appreciate it. Its currently 10x slower than my python version that is not segmented. http://paste.ofcode.org/TKmny9WL2jCiAzdFpfTyY5 |
08:46:36 | Araq | hi Guest86655, use 'result' in 'prime_sieve_s' directly, not 'result = primes' |
08:46:41 | Araq | use -d:release |
08:46:52 | * | vendethiel joined #nim |
08:47:43 | Guest86655 | Cheers Araq! |
08:47:57 | Varriount | Guest62515: Does your code work with sequences and strings? If so, be aware that both those data types are copy-on-assignment. |
08:48:35 | Araq | probably there is something else wrong with this code if it's 10x slower than python ;-) |
08:48:57 | Araq | but right now I cannot see it and I'm too lazy to run it in a profiler |
08:48:57 | Varriount | Araq: Not wrong, just unoptimizes |
08:49:05 | Varriount | *unoptimized |
08:50:23 | Guest86655 | Thanks, its just sequences and an array which i set to 0 with zeroMem as its needed lots. |
08:50:28 | Araq | Varriount: no, it could also be wrong. lot of 'countup' bounds that could be off, so Nim has to iterate 100x more than Python |
08:51:07 | Guest86655 | Is it really that much faster to use result rather than setting it at the end? |
08:51:37 | Araq | no, for your example it's likely irrelevant since you call prime_sieve_s only once |
08:51:50 | Guest86655 | Thought so. But cheers! |
08:51:52 | Araq | but in general it's a copy vs a move |
08:51:56 | Varriount | Guest62515: Well, for the first procedure in that code, `result = primes` will copy `primes` |
08:52:15 | Guest86655 | would it be easier to just return primes? |
08:52:33 | Varriount | Guest62515: That would work too... I think. |
08:52:54 | Varriount | Araq would know for sure how 'return' is done. |
08:53:03 | Araq | I don't think the compiler does that right now |
08:53:04 | Guest86655 | I mean it does work, I just don't yet see why the result variable is there. I was just using it as i read about it early on |
08:53:19 | Araq | #sieve size to fit in cache |
08:53:20 | Araq | const sievesize:int=1 shl 19 |
08:53:57 | Guest86655 | with my c++ implementation I could get it to fit in the cache and it was much faster, hence the segmented sieve |
08:54:24 | Guest86655 | i've been trouble finding the right value for this. its currently at half the python time now with the command line switches |
08:55:42 | Guest86655 | I don't think nim likes how i use the bit array as is using unsigned uint8's. there is no native bit array is there? |
08:56:32 | Varriount | Guest62515: Have you actually used a profiler on the code? |
08:56:34 | Araq | there is an intsets stdlib module |
08:57:05 | Araq | my guess is you call zeroMem way too often |
08:57:22 | Araq | always resetting everything which is not necessary |
08:57:38 | Guest86655 | hmm you just gave me a fantastic idea |
08:57:40 | Guest86655 | cheers |
08:57:43 | Araq | you can store a runtime "max used bit" in your 'proc set' |
08:58:03 | Araq | and use that for clearing 'arr' |
08:58:12 | Guest86655 | as i iterate through afterwards getting the primes, i can set the bit to 0 |
08:58:39 | Guest86655 | you have a point with that also |
08:58:42 | Araq | or that, but this could be slower |
08:59:07 | Araq | also try a smaller cache size |
08:59:42 | Araq | L1 cache is usually smaller, 32KB |
09:00:15 | Araq | oh wait, I have 128KB :P |
09:00:41 | Guest86655 | yeah. Will do thanks. I'm just trying to find the best ways to actually use nim. I know it can be fast, i just haven't been able to achieve that yet ha. Yes indeed. Cheers. Sometimes its best to fit it in L2 if the primes you iterate through is large enough I assume. |
09:01:33 | Araq | yeah but you use ALL of L2 |
09:01:47 | Araq | no room left for code and helper variables |
09:02:24 | Guest86655 | hmm. Valid point. |
09:02:36 | Araq | but then there is also L3 cache ... so ... I have no idea |
09:03:33 | Guest86655 | ha yeah i'll work with the cache. its more just the use of the commands i'm looking for improvements in. I'll quickly whip up a identical python script to test in pypy |
09:04:21 | Araq | ah ok! so you do compare to pypy :-) |
09:05:55 | Guest86655 | yeah :D |
09:06:45 | Guest86655 | is there any way to use pythons bitshifts and mod etc instead of having to explicitly type shr and what not? |
09:08:10 | Araq | template `<<` (a, b): untyped = a shl b |
09:08:41 | Araq | but << then has the precedence of < so that's why we don't do that |
09:09:00 | Guest86655 | Oh i see |
09:09:11 | Araq | renesac uses *< and *> so they have multiplicative precedence |
09:09:33 | * | vendethiel quit (Ping timeout: 255 seconds) |
09:21:00 | * | vendethiel joined #nim |
09:37:26 | r-ku | Araq: cant build 64 bit compiler on windows? |
09:37:59 | Araq | use build64.bat ? |
09:42:38 | * | vendethiel quit (Ping timeout: 248 seconds) |
09:43:52 | Araq | 8888 posts on our forum :-) |
09:46:08 | r-ku | Araq: somehow doesnt work. assert_numbits thing fails. adding -m64 in build64.bat results in c_code\1_2\compiler_nim.c:1:0: sorry, unimplemented: 64-bit mode not compiled in |
09:56:34 | r-ku | build.bat works by the way, building 32 bit executable |
09:59:17 | * | Kingsquee quit (Quit: Konversation terminated!) |
10:05:38 | coffeepot | that's weird, I'm sure I used the build64 batch file on devel |
10:06:24 | r-ku | well i merged devel yesterday |
10:06:38 | r-ku | coffeepot: what compiler did you use? im using mingw myself |
10:06:40 | coffeepot | ah well it was a few weeks ago now for me |
10:07:04 | coffeepot | I literally just used git to pull over devel and did the normal install procedure but with buil64 |
10:07:12 | Araq | if assert_numbits fails your setup is wrong |
10:07:45 | coffeepot | ofc you gotta make sure any dlls are 64bit |
10:08:03 | Araq | bootstrapping doesn't use DLLs |
10:08:06 | r-ku | adding -m64 makes it go away Araq, but why c_code/1_2 has no 64 bit mode implemented as error says? |
10:08:20 | coffeepot | ah yes but nimble does I think |
10:08:24 | Araq | 1_2 is the 32 bit variant |
10:08:30 | Araq | 2_2 should be win64 |
10:09:05 | r-ku | build.bat uses 1_1 and build64.bat uses 1_2 |
10:09:24 | r-ku | and build.bat correctly builds 32 bit executable |
10:10:03 | Araq | oh ok, so it's 1_1 and 1_2 |
10:10:05 | Araq | sounds right |
10:12:34 | coffeepot | I think... I may have downloaded the 0.11.2 release in 64 bit, installed that and later decided to move to devel so used the dist from the 0.11.2 package :3 |
10:14:28 | coffeepot | so with a fresh devel folder but with the 0.11.2 bundled mingw |
10:17:18 | * | k1i quit (Ping timeout: 248 seconds) |
10:18:52 | * | k1i joined #nim |
10:19:11 | r-ku | well someone needs to do some testing in that area |
10:19:56 | Araq | r-ku: http://buildbot.nim-lang.org/builders |
10:20:11 | Araq | http://buildbot.nim-lang.org/builders/windows-x64-builder/builds/465 |
10:28:31 | * | vendethiel joined #nim |
10:31:56 | * | vendethiel- joined #nim |
10:32:51 | * | vendethiel quit (Ping timeout: 252 seconds) |
10:38:39 | * | bjz joined #nim |
11:05:14 | * | raza joined #nim |
11:05:25 | r-ku | Araq: build bots do not serve built binaries? |
11:06:28 | r-ku | also what compiler actually those buildbots are using? |
11:13:33 | * | arnetheduck quit (Ping timeout: 246 seconds) |
11:15:28 | * | dom96_ joined #nim |
11:16:28 | dom96_ | r-ku: http://build.nim-lang.org/ has binaries |
11:17:08 | dom96_ | Only linux though |
11:17:17 | dom96_ | I need to revive NimBuild |
11:25:50 | * | arnetheduck joined #nim |
11:40:36 | * | wtw quit (Ping timeout: 264 seconds) |
12:05:26 | * | zemm quit (Ping timeout: 264 seconds) |
12:06:23 | * | arnetheduck quit (Quit: Leaving) |
12:08:03 | * | dom96_ quit (Ping timeout: 246 seconds) |
12:10:11 | * | ozra joined #nim |
12:11:23 | * | joebo quit (Quit: WeeChat 1.1.1) |
12:14:19 | * | UberLambda joined #nim |
12:26:15 | * | zemm joined #nim |
12:27:18 | * | ozra quit (Ping timeout: 246 seconds) |
12:38:02 | * | OnwardEuler joined #nim |
12:52:37 | * | Onward_Euler joined #nim |
12:52:50 | * | zephyz joined #nim |
12:55:57 | * | OnwardEuler quit (Ping timeout: 265 seconds) |
12:58:11 | * | drewsrem joined #nim |
13:00:31 | r-ku | yeah dom96 i need windows x64 build so i can test windows x64 coroutines. linux 32/64 bit + windows 32 bit tested and work. got code for windows x64 too but it will most likely fail as its not tested |
13:01:40 | drewsrem | Is there any way to allow identifier starting with _ ? |
13:01:49 | drewsrem | Like quoting them or something? |
13:03:54 | * | Onward_Euler is now known as OnwardEuler |
13:04:23 | Araq | drewsrem: I don't think so. |
13:06:13 | drewsrem | They seem a bit like nuisance to work around with when wrapping/using clibs |
13:06:24 | drewsrem | But nothing big |
13:07:12 | Araq | well wrappers should adhere to NEP1 too |
13:07:25 | Araq | which c2nim supports via the --nep1 switch |
13:07:50 | Araq | actually it should be the default but c2nim's defaults are all crappy |
13:08:49 | * | EXetoC joined #nim |
13:12:17 | drewsrem | Right, in my case it's the usage of the plain c2nim ported clib, the example I'm porting uses an enum to both index an array and the field names of the enum correspond to strings the interface makes use of and they just happen to use underscore-prefixed-commands. |
13:12:37 | drewsrem | So I just need to do it differently |
13:13:07 | drewsrem | But I'm 1:1 copying/porting c-code here, so it probably can be done better in nim anyway |
13:13:31 | Araq | yeah, for example $ works for enums out of the box |
13:14:46 | drewsrem | Right, so that'd work, but e.g. the enum has a field named "_FOO" and you're supposed to pass that cstring to an API, now I can't call the enum-field "_FOO", but "uFOO" but then I can't just pass it to the API anymore, but would have to replace it or something |
13:15:25 | drewsrem | I should probably just show you some code if you care, but I don't think it's too interesting anyway |
13:15:41 | drewsrem | Just can't use enums for this like they do in C |
13:16:49 | fowl | Yes you can drewsem |
13:17:21 | fowl | Enum a = (1,"_a"), ... |
13:17:32 | Araq | OnO: why are colors disabled with --stdout too? |
13:18:31 | fowl | For stringification at least, in general c enum members should just be consts |
13:18:31 | Araq | I thought --stdout should become the default on Unix anyway, so the precious stdout stream is available ... for something ... |
13:19:07 | drewsrem | fowl, right, I just realized it uses some macro stuff for C... |
13:19:16 | Araq | (for what? gcc doesn't spill out a.out on stdout either) |
13:21:21 | drewsrem | fowl, if you care: http://ix.io/jLq |
13:25:24 | Araq | drewsrem: do you wrap x11? there is already a wrapper for that |
13:25:25 | drewsrem | So it uses the identifiers of the enum to index an array, but they also correspond to API-calls which are passed to as cstrings |
13:25:31 | drewsrem | Araq, I partially wrapped xcb |
13:25:40 | bogen | Araq: Well, while gcc won't put a.out on stdout, it will output aseembly on stdout |
13:25:40 | bogen | printf '#include <stdio.h>\nvoid main(){printf ("hello world!\\n");}' | gcc -o- -x c - # yeah, that outputs to a file named - |
13:25:40 | bogen | printf '#include <stdio.h>\nvoid main(){printf ("hello world!\\n");}' | gcc -S -o- -x c - #outputs assembly |
13:25:59 | drewsrem | Araq, x11 AFAIS uses xlib |
13:27:15 | drewsrem | Araq, I really didn't had to do much of anything thanks to c2nim :), enjoying this very much so |
13:28:05 | Araq | bogen: bah, now I need to figure out how to get rid of this useless piece of information |
13:28:14 | Araq | ;-) |
13:29:33 | Araq | drewsrem: afaict your snippet is an excercise of how to simulate $ for enums :P |
13:29:59 | reactormonk | Araq, don't we have $ for enum? |
13:30:10 | Araq | reactormonk: yes but C lacks it. |
13:30:28 | reactormonk | all hail nim \o/ |
13:30:55 | drewsrem | Araq, right, it would be perfect if I could name the enum "field-identifiers" as starting with an underscore :P |
13:31:17 | reactormonk | drewsrem, you can, via importc I'd say |
13:31:25 | reactormonk | or exportc, depending on what you need |
13:31:44 | * | FedeOmoto joined #nim |
13:32:15 | drewsrem | But I think I understood fowl now, so I'm just going to do: a = enum \n uFOO = (0, "_FOO"), uBAR = (1, "_BAR") |
13:32:32 | Araq | or just use a .pure enum |
13:33:37 | drewsrem | Araq, how does that help me? - does it let me use underscore-prefixed identifier for the enum fields? |
13:33:51 | Araq | no. |
13:34:13 | Araq | but I don't get why the underscore is so important. by definition it carries no semantics. |
13:34:48 | fowl | Im curious too |
13:35:17 | drewsrem | Because I can stringify them via $ and then pass them to the API, the API takes them as strings: xcb_intern_atom_cookie_t xcb_intern_atom(xcb_connection_t *conn, uint8_t only_if_exists, uint16_t name_len, const char *name); |
13:35:23 | fowl | And most problems with c identifiers are solved with importc:"_$1" |
13:35:38 | drewsrem | const char *name |
13:35:44 | reactormonk | fowl, ^ nice one |
13:35:56 | drewsrem | That's the only reason |
13:36:02 | * | dalarmmst joined #nim |
13:36:03 | Araq | proc `$`(x: MyEnum): string = "_" & system.`$`(x) |
13:36:22 | drewsrem | Problem is that not all enum fields are prefixed with underscores, some aren't |
13:36:49 | drewsrem | But I guess I could find some rule how to replace them |
13:36:55 | Araq | wrap wayland instead? :P |
13:37:00 | fowl | Yes |
13:37:40 | fowl | Work on new monoliths not old ones :p |
13:37:54 | drewsrem | I'm actually more confident in X11 becoming better then wayland replacing X11 all of the sudden :P |
13:38:25 | reactormonk | drewsrem, probably too much legacy compat |
13:38:32 | fowl | drewsrem we dont generally keep the same names in nim as c |
13:39:30 | Araq | yup. we don't hate vowels for a start. |
13:40:13 | drewsrem | It's not really an issue tho anyway |
13:40:22 | drewsrem | I just can't do it exactly like the example does |
13:40:24 | EXetoC | x11 just seems like a mess judging by the presentation I watched, and many former x11 devs have migrated to wayland. I assume they have their reasons |
13:40:38 | EXetoC | a lot of momentum is needed though |
13:41:36 | drewsrem | Wayland is very meh tho because it leaves so much open to the widget-toolkit-guys, what X11 does well is it enables lonseome people to write powerful window-managers like i3/awesome-wm etc., in wayland you have to go ask the widget-toolkit for example to please not draw any borders around your windows, because there's no generalized API in wayland itself |
13:42:20 | Araq | hrm now I feel like trying out a linux distro that uses wayland. any suggestions? |
13:42:27 | fowl | So wm is now widget toolkit? Sounds great |
13:42:32 | drewsrem | Araq, archlinux |
13:42:38 | EXetoC | but such abstractions will emerge at some point surely |
13:42:52 | bogen | drewsrem: heh, was going to say the same thing... |
13:42:53 | r-ku | fedora could run gnome on wayland afaik |
13:43:02 | EXetoC | if they haven't already |
13:43:13 | drewsrem | The difference is that you have to deal with the widget-toolkit guys, X11 has a lot of ancient concepts, but its very centralized |
13:43:33 | drewsrem | Araq, https://github.com/Cloudef/orbment |
13:44:14 | drewsrem | But I have no idea what is going to happen in the future, just atm I'm not that hyped about it and X11 is getting a lot better recently |
13:44:57 | drewsrem | Araq, AFAIS it's a lot of work tho to get the wayland stuff going |
13:45:27 | Araq | yay, bright grey on darker grey |
13:45:58 | drewsrem | Well, gotta love your minimalism on Linux or why else are you using it :) |
13:46:30 | drewsrem | But KDE might be Wayland ready already |
13:46:43 | drewsrem | I don't follow this stuff |
13:47:01 | r-ku | its not, but is getting there |
13:47:31 | EXetoC | is that color scheme available somewhere? |
13:47:32 | r-ku | but still some basic things like copying text from xwayland to wayland window no workie.. (on gnome too i think) |
13:47:33 | Araq | my /usr/bin had over 100 binaries iirc and the typical distro doesn't fit on a CD anymore. what kind of minimalism do you have in mind? |
13:49:11 | drewsrem | Araq, the interface work-flow window-manager thingies are usually rather minimal |
13:50:11 | drewsrem | but yeah, "minimalism" is overused |
13:50:56 | drewsrem | I can only say that i3 brings me daily joy, still after 2 years, so I guess whatever floats your boat |
13:54:54 | drewsrem | back to dealing with this c-api so I can do really simple things in a really hard complicated way... |
13:56:58 | federico3 | yay for i3 |
14:01:08 | * | vendethiel- is now known as vendethiel |
14:02:23 | * | bogen quit (Quit: Leaving.) |
14:02:47 | * | bogen joined #nim |
14:12:55 | * | yglukhov_____ joined #nim |
14:17:03 | Araq | bogen: oh btw using cling for a REPL has been brought up before. It's a good idea and feel free to work on it |
14:17:31 | * | brson joined #nim |
14:18:50 | * | Demos joined #nim |
14:21:19 | Araq | r-ku, fowl any objections about making currentModule a proc? |
14:21:34 | Araq | this way we could use the plugin mechanism for this feature |
14:22:30 | Araq | oh well we can use the plugin mechanism anyway |
14:22:48 | r-ku | Araq: it would be awkward but if its easier... can always deprecate it later |
14:23:53 | r-ku | btw 64 bit build on windows might be my gcc not being able to build x64. i totally did not expect that :| |
14:24:28 | Araq | the plugin system supports constants easily anyway, so never mind |
14:25:07 | r-ku | awesome \o/ |
14:26:49 | * | aziz_ joined #nim |
14:27:26 | Araq | is it CurrentModule or currentModule? |
14:28:10 | r-ku | follow same style as other constants |
14:28:19 | * | zephyz quit () |
14:28:51 | r-ku | there are CompileTime and cpuEndian. uh.. |
14:29:01 | r-ku | well idk whats the correct nim style, you know better |
14:29:19 | Araq | ". All other identifiers should be in camelCase with the exception of constants which may use PascalCase but are not required to." |
14:29:38 | Araq | so ... I'll use currentModule |
14:29:58 | r-ku | i would take that "but are not required to" out. things should be consistent in one project |
14:30:31 | Araq | ping Varriount |
14:32:19 | Araq | I still think these should be in a new module |
14:32:47 | Araq | currentmodule.name, currentmodule.file, currentmodule.dir |
14:34:37 | fowl | Araq all of those are accessible from system.currentSourcePath |
14:34:41 | r-ku | having currentModule entity serving these 3 properties suggests there could be more stuff to do with it |
14:35:09 | r-ku | think there gonna be more in the future? |
14:35:16 | Araq | we have a system.currentSourcePath ? |
14:35:26 | fowl | Yes omg its great |
14:35:44 | r-ku | template currentSourcePath*: string = instantiationInfo(-1, true).filename |
14:35:46 | r-ku | wow |
14:36:03 | fowl | http://nim-lang.org/docs/system.html#currentSourcePath.t, |
14:36:19 | Araq | well then we don't need currentModule stuff, do we? |
14:36:32 | fowl | I dont think so |
14:36:51 | EXetoC | you should know what's in there :p |
14:37:03 | EXetoC | jk |
14:37:10 | drewsrem | Does it make sense to include a "proc len" for enums? |
14:37:12 | r-ku | its probably very rare case when this kind of thing is needed yeah |
14:37:15 | fowl | I use os.splitpath.head to refer to this module dir. Works great for c sources in nimble package |
14:37:48 | r-ku | fowl: is there any proc that extracts dir path from file path? |
14:37:53 | Araq | drewsrem: no. |
14:38:11 | Araq | r-ku: os.extractDir |
14:38:26 | r-ku | awesome, thanks |
14:38:40 | Araq | or splitFile(f).dir |
14:38:50 | EXetoC | iterating over enum members is another use of getType |
14:38:58 | fowl | Shortcuts would be good tho |
14:39:16 | r-ku | Araq: we really should move error/warning/hint to system.. |
14:39:27 | Araq | no way |
14:39:32 | r-ku | they arent exclusively needed when doing macros |
14:39:45 | EXetoC | excluding those pesky holes \o/ |
14:39:48 | Araq | they only work in macros |
14:40:02 | Araq | but we also have {.error: "foo".} |
14:40:11 | r-ku | ohh |
14:40:14 | r-ku | didnt know |
14:40:18 | r-ku | that solves it then \o/ |
14:40:18 | Araq | don't ask why, this stuff has grown |
14:40:18 | fowl | Magic thismodule symbol might be useful for templates |
14:43:07 | r-ku | fowl: whats usecase for that? |
14:45:08 | r-ku | damn this msys2 thing is nice |
14:45:19 | r-ku | it has pacman as package manager (on windows!!) |
14:45:45 | * | Onward_Euler joined #nim |
14:46:36 | UberLambda | Do you think there is any need for RAII? I'm currently using try...finally blocks but it just doesn't feel the same |
14:46:53 | coffeepot | don't forget defer: too |
14:46:57 | UberLambda | Or is there a better approach at things like closing streams, etc? |
14:47:00 | EXetoC | wasn't there a point when there was neither a package manager nor a bundle of sorts? |
14:47:25 | EXetoC | or was that cygwin? but what a pain in the ass |
14:47:34 | UberLambda | coffeepot: hm, I had no idea it existed... it's like python's 'with' statement? |
14:48:06 | coffeepot | hmm not really used python's with, but it's kind of syntactic sugar for try finally |
14:48:09 | Araq | UberLambda: we have proc `=destroy`(x: var Foo) for destuctors in the language but currently they don't work too well |
14:48:10 | r-ku | EXetoC: i know nothing of package managers in original msys (v1.0). cygwin had pkg manager for a long time. |
14:48:12 | * | xet7 joined #nim |
14:48:26 | coffeepot | f = openFile... defer: closefile(f) |
14:48:28 | UberLambda | Araq: I've tried them, but they never got executed :( |
14:48:57 | * | OnwardEuler quit (Ping timeout: 244 seconds) |
14:49:05 | UberLambda | even with the {.destructor.} pragma on them |
14:49:20 | Araq | don't test them in top level statements |
14:49:38 | UberLambda | Araq: so I should wrap the code in a function? |
14:49:41 | UberLambda | *proc |
14:49:51 | coffeepot | ahem, sorry i guess you found this already uberlambda http://nim-lang.org/docs/manual.html#exception-handling-defer-statement |
14:49:51 | Araq | for destructors to work, yes |
14:50:11 | UberLambda | coffeepot: thanks for the tip :D |
14:50:45 | coffeepot | aren't destructors only for the type? Or is that finalizers... |
14:51:06 | UberLambda | Araq: I'll try them...but are they really bugged, like "executed twice" bugged? If so I think I'll just use defer |
14:51:32 | Araq | try it |
14:52:15 | UberLambda | Also, one thing... when I have a "ref object of ...", is every instance of that passed as reference? Or are they copied everytime they're passed to a function? |
14:52:34 | UberLambda | I don't quite understand how passing in general works |
14:53:01 | Araq | a ref object works like a Java/C# class |
14:53:39 | UberLambda | so... always passed by reference then? |
14:53:59 | UberLambda | In C++ terms I mean |
14:54:00 | * | BitPuffin|osx joined #nim |
14:54:01 | Araq | not really, passed by value but the value is a pointer |
14:54:16 | * | aziz_ quit (Remote host closed the connection) |
14:54:24 | UberLambda | Hm, well, atleast they do not get deep copied everytime |
14:54:46 | Araq | it's like a C++ typedef struct SomeStruct* RefObject; |
14:55:07 | Araq | and then RefObject still is a pointer but the pointer is copied |
14:55:10 | UberLambda | Araq: oh, it's clearer now, thanks |
14:55:41 | * | zephyz joined #nim |
14:56:53 | Araq | UberLambda: "I don't quite understand how passing works". In C++ terms everything is passed by const& T except as an optimization the compiler is free to pass T directly by copy too. |
14:56:54 | * | xet7 quit (Quit: AndroIRC - Android IRC Client ( http://www.androirc.com )) |
14:57:12 | Araq | and it does so for a small T |
14:57:33 | drewsrem | Is it possible to maintain some state between macro calls? - i.e. I'd like to have a macro foo that adds elements to a sequence on each call and then a call to bar runs over those and does things with them |
14:57:37 | r-ku | when i ``import os`` in my arch.nim module i get strutils.nim(244, 3) Error: undeclared identifier: 'assert'.. why? :\ that file -> https://github.com/r-ku/Nim/blob/coroutines/lib/arch/arch.nim |
14:57:49 | Araq | where "small" means <= sizeof(float)*2 iirc |
14:59:01 | coffeepot | Araq: why is it ever considered an optimisation to copy a struct rather than pass a pointer (if I understand correctly)? |
14:59:21 | coffeepot | hang on |
14:59:31 | UberLambda | Araq: wait... no difference between "void a(const std::string a)" and "void b(const std::string& b)" ? |
14:59:45 | coffeepot | thought about it for more than 2 seconds, I'm guessing CPU cache being one reason |
14:59:53 | Araq | coffeepot: because the "copy" can mean a "mov rax, rbx" |
15:00:14 | UberLambda | Yeah but that's an optimization right? Not actually in the language "standard" |
15:00:41 | UberLambda | Or the standard specifies what the compilers can/can't do in these situations? |
15:00:54 | r-ku | this to me sounds like value vs reference semantics. like strings and lists in python for example. |
15:00:54 | Araq | yeah but it's an implementation detail that leaks |
15:01:07 | Araq | thanks to aliasing ... |
15:01:27 | Araq | fortunately there are ways to detect this eventually |
15:01:31 | UberLambda | Hm... so, what happens in nim when I pass a plain object? |
15:01:41 | UberLambda | Does it get deep copied then? |
15:01:55 | Araq | it depends on the size of the object |
15:02:03 | UberLambda | Nice |
15:02:22 | Araq | and also whether the object uses GC'ed memory for reasons that are too complex to explain here :P |
15:03:05 | UberLambda | I guess I don't have to worry too much about what kind of structures to use then... that's a problem less to solve, yay |
15:03:34 | Araq | yeah, it works really well in practice. it's like C++ should have done it. |
15:03:37 | coffeepot | "mov rax, rbx" ah nice |
15:03:56 | UberLambda | But why does most code define a "object XyzObj" and then define "Xyz" as "ref XyzObj"? |
15:04:08 | UberLambda | I mean, most code that I've seen in the standard library atleast |
15:04:13 | Araq | UberLambda: legacy |
15:04:19 | Araq | 'ref object' came later |
15:04:31 | UberLambda | Araq: oh, that explains it. Thanks :D |
15:09:38 | r-ku | Araq: wth..? Error: system module needs 'copyStrLast' |
15:09:51 | r-ku | all because i use substr() |
15:10:16 | Araq | r-ku: do you use your arch stuff from system? |
15:10:22 | r-ku | no |
15:10:38 | UberLambda | company-nim is pretty broken... if you consider that it spawned ~100ish nimsuggest processes, lol |
15:10:44 | Araq | well you use substr() too early then :P |
15:11:16 | r-ku | coro.nim is my test case which imports arch.nim, and arch.nim tries to use substr |
15:11:20 | r-ku | how the hell can it be too early? |
15:11:44 | * | yglukhov_____ quit (Quit: Be back later ...) |
15:12:19 | Araq | before the compiler processed system/sysstr and so knows where to find copyStrLast |
15:13:11 | Araq | are you sure you didn't touch anything in the system module? |
15:13:20 | * | bogen-work quit (Quit: Lost terminal) |
15:14:52 | r-ku | 100% positive, i have no business in system.nim |
15:15:10 | Araq | shouldn't the GC use your new asm based stuff? |
15:15:21 | r-ku | ohhhh |
15:15:24 | Araq | didn't you modify the GC? |
15:15:30 | r-ku | i forget that gc stuff is included, not imported |
15:15:36 | Araq | aye |
15:16:11 | r-ku | but its included way after substr() |
15:16:14 | r-ku | shouldnt it work? |
15:16:40 | Araq | it comes before sysstr though |
15:17:01 | Araq | what do you use it for anyway? |
15:17:22 | r-ku | oh. i want to extract path from filename |
15:17:41 | r-ku | its used in passL to point to obj file compiled from asm |
15:18:08 | Araq | so it is evaluated at compile-time? |
15:18:15 | r-ku | yes |
15:18:26 | Araq | hrm then it should work |
15:18:43 | r-ku | {.passL: extractDir(currentSourcePath) "/" & ABI & "_" & hostCPU & objExt} - compile time right? |
15:20:14 | Araq | er yeah but |
15:20:25 | Araq | so you import os.nim from system.nim |
15:20:37 | Araq | that is not supported |
15:20:56 | r-ku | well in current testcase i did not import it cause it yielded error. tried to reimplement extractDir myself only to find out i cant use substr |
15:21:12 | Araq | yeah you can |
15:21:23 | Araq | you need to mark your extractDir with .compileTime |
15:22:09 | r-ku | done. Error: undeclared identifier: 'currentSourcePath' |
15:22:31 | Araq | see? there is progress! |
15:22:45 | r-ku | i see waist-deep mess :D |
15:23:37 | Araq | i told you I want compiler support for the external assembler |
15:23:41 | * | vasher_ joined #nim |
15:23:48 | Araq | you knew better and now see where that got you :P |
15:24:14 | r-ku | nah it was more like now knowing how to do it properly so.. here we are :D |
15:24:18 | Araq | but you only need to move the declaration of currentSourcePath and instantionInfo around |
15:25:12 | r-ku | nah.. {.passL: extractDir(instantiationInfo(-1, true).filename) & "/" & ABI & "_" & hostCPU & objExt} - Error: undeclared identifier: 'instantiationInfo' |
15:25:14 | * | UberLambda quit (Ping timeout: 264 seconds) |
15:25:24 | r-ku | but hey - maybe you are bored and want to implement external assembler support? :D |
15:25:42 | Araq | ok |
15:26:18 | Araq | actually i implemented caching for staticExec |
15:26:34 | Araq | you can call the assembler via staticExec, right? |
15:27:02 | r-ku | err no idea, idk how staticExec works even |
15:27:46 | r-ku | ah i see. that sounds useful |
15:27:52 | Araq | how do you invoke the assembler then? |
15:28:01 | r-ku | currently i just stick fasm execution on koch boot step |
15:30:10 | r-ku | not sure how staticExec caching should even work. compiler doesnt know about output of external program.. |
15:32:59 | Araq | {.passL: staticExec("fasm " & hostCPU & ".asm", "", NimVersion).} |
15:33:14 | Araq | and fasm should output only the name of the produces object file :P |
15:33:21 | Araq | *produced |
15:33:30 | r-ku | but it doesnt |
15:37:18 | Araq | what is its output? |
15:38:25 | r-ku | you can call the assembler via staticExec, right? bler version 1.71.39 (16384 kilobytes memory) |
15:38:27 | r-ku | 2 passes, 787 bytes. |
15:38:33 | r-ku | garbage.. |
15:38:57 | * | sparrk joined #nim |
15:39:00 | r-ku | heh that old text should not be on first line start |
15:39:14 | sparrk | Is it possible to determine the type of something at runtime? |
15:39:34 | Araq | sparrk: if foo of Subtype |
15:39:44 | Araq | works for objects only |
15:40:00 | Araq | but for the other things you already know at compile-time |
15:40:24 | sparrk | So that is what I'm doing. Maybe I'm misunderstanding the JSON library. Is there an example of someone parsing an api that they do not know the structure of ahead of time? |
15:40:39 | sparrk | And thanks for your help again Araq |
15:41:32 | Araq | well the JSON library returns a Json object that can represent every JSON data including "schemaless" data |
15:41:58 | Araq | however if it's schemaless you can convert it into a Nim object with fixed fields |
15:42:03 | Araq | *you cannot |
15:42:41 | * | raza quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) |
15:42:55 | Araq | so you have to use data["field"]["fieldB"] rather than specializedObject.field.fieldB |
15:43:09 | Araq | but no big deal, is it? |
15:44:53 | Araq | r-ku: const dummy = staticExec("..."); {.passL: "foo.obj".} |
15:45:17 | r-ku | so... can build wrapper executable that would call assembler and print input path to stdout.. can try to modify fasm itself but i dont think its optimal.. or you can implement external assembler support into compiler |
15:45:25 | r-ku | we kind of have to use absolute paths in passL |
15:45:33 | r-ku | cause it works relative to project root |
15:45:38 | * | sparrk quit (Ping timeout: 264 seconds) |
15:47:15 | * | raza joined #nim |
15:48:58 | Araq | ok, ok, I know how to do it |
15:50:09 | r-ku | im all ears |
15:52:41 | * | darkf quit (Quit: Leaving) |
15:52:50 | Araq | we planned to support {.compile: "foo.cpp".} to invoke the C++ compiler even when in C mode |
15:53:08 | Araq | so .compile should do some file extension detection |
15:53:17 | Araq | and might as well detect .asm files |
15:54:11 | Araq | to reuse as much as possible from the existing logic, we will treat fasm as yet another C compiler |
15:54:24 | Araq | so only extccomp.nim needs to be modified |
15:54:29 | Araq | you can do it |
15:55:00 | r-ku | sounds good. although i bet we want to be able to use any assembler right? because its possible we will need other assembler for arm |
15:55:09 | r-ku | certainly other assemblers for other more weird archs |
15:55:23 | EXetoC | I like abstractions |
15:55:37 | Araq | EXetoC: pfff |
15:55:47 | r-ku | so.. like adding it to nim.cfg somehow? |
15:56:21 | Araq | well that comes out of the box when you treat it as a c compiler |
15:56:31 | Araq | C compilers can be configured already |
15:56:51 | r-ku | ah, so picking different compiler based on extension |
15:56:53 | r-ku | got it |
15:57:16 | EXetoC | I wasn't referring to the low level nature of asm :p |
15:57:20 | r-ku | however.. doesnt it imply we would have to have different extensions for different archs (when different assemblers used)? |
15:57:36 | * | sparrk joined #nim |
15:57:47 | Araq | no you can override it in the config anyway |
15:58:09 | r-ku | what i mean is i think we would want one config that works on all archs |
15:58:17 | Araq | perhaps the config is not flexible enough but I think it is |
15:58:25 | r-ku | oh unless we can if/else based on environment in config |
15:58:31 | Araq | exactly |
15:58:39 | Araq | and we can |
15:58:59 | sparrk | So I found my answer. I can do value.kind. Thanks for your help! |
15:59:31 | Araq | sparrk: ah that's what you're after |
16:05:22 | r-ku | err Araq.. {.compile.} not even implemented yet or i just cant find it? |
16:06:44 | * | Onward__Euler joined #nim |
16:06:48 | Araq | nimc.html |
16:06:51 | * | Demos quit (Remote host closed the connection) |
16:06:56 | Xe | r-ku: {. compile: "foo.c" .} |
16:07:15 | Xe | r-ku: http://nim-lang.org/docs/nimc.html#additional-features-compile-pragma |
16:07:47 | r-ku | oh ok, ill keep looking for it |
16:08:18 | r-ku | ahh right.. wCompile |
16:09:39 | * | Guest86655 quit (Quit: Leaving) |
16:09:39 | * | Onward_Euler quit (Ping timeout: 246 seconds) |
16:09:50 | * | vendethiel quit (Ping timeout: 250 seconds) |
16:16:01 | * | vendethiel joined #nim |
16:16:35 | * | coffeepot quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) |
16:17:36 | * | raza quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) |
16:17:58 | * | raza joined #nim |
16:18:15 | sparrk | Is it possible to append to an existing set? |
16:18:42 | sparrk | Other than doing x = x + y |
16:21:22 | EXetoC | with incl, as seen here: http://nim-lang.org/docs/manual.html#types-set-type |
16:24:21 | sparrk | Ah, thanks, how did I miss that |
16:32:17 | EXetoC | I dunno d(:D)|< |
16:38:39 | * | zephyz quit (Ping timeout: 255 seconds) |
16:40:25 | * | bogen-work joined #nim |
16:42:54 | * | sparrk quit (Read error: Connection reset by peer) |
16:53:22 | * | Demos joined #nim |
16:58:39 | * | Onward_Euler joined #nim |
17:00:34 | federico3 | some documentation on how to implement packet generation/parsing would be nice. |
17:01:03 | federico3 | any pointers? |
17:01:41 | Demos | what level |
17:02:03 | * | Onward__Euler quit (Ping timeout: 255 seconds) |
17:05:32 | federico3 | Demos? |
17:05:39 | Demos | yes? |
17:06:00 | federico3 | "what level"? |
17:06:40 | Demos | like are you trying to parse Application level headers or generate IP headers |
17:06:46 | Demos | or like maybe even link-level frames |
17:07:09 | Demos | my recomendations for all but app level is "use BSD sockets" |
17:08:44 | * | filcuc joined #nim |
17:09:35 | EXetoC | or one of the libraries abstracting over BSD sockets and winsock |
17:10:34 | EXetoC | or could you actually re-implement that part of the stack with BSD sockets? |
17:22:55 | federico3 | Demos: generating or parsing IP | UDP | ICMP, think Scapy |
17:24:54 | Demos | how does scapy give you packets, I would kinda expect it to give you the raw data |
17:25:55 | federico3 | Demos: yep - and it's awesome: http://www.secdev.org/projects/scapy/doc/usage.html#stacking-layers |
17:26:35 | Demos | it's a command line tool? |
17:27:01 | * | xcombelle joined #nim |
17:27:07 | federico3 | no, from its own shell or the Python interpreter |
17:27:16 | Demos | ugh, that's really annoying |
17:27:21 | federico3 | why? |
17:27:49 | Demos | because we wrap sockets.h and if it was a native lib you could just copy the packet into some memory and look at it via the struct |
17:27:55 | Demos | same as when you sent it |
17:28:29 | federico3 | *if* scapy was written in C? :) |
17:28:36 | Demos | right |
17:29:07 | * | elbow_jason quit (Ping timeout: 244 seconds) |
17:29:21 | federico3 | nobody dared to implement it in C so far |
17:30:12 | Demos | well yeah, the packet sniffer in C is just using sockets.h to sniff packets |
17:30:14 | federico3 | but if somebody is interested in doing it in Nim... |
17:30:21 | drewsrem | I'm assuming something went wrong with my c2nim wrapper-generation when porting an example over from C crashes whenever I try to free a returned ptr and run it through Valgrind... |
17:30:28 | Demos | anyway for scapy I'd just parse the strings that it outputs I guess |
17:30:45 | Demos | pointer returned from what? |
17:30:54 | federico3 | well, sniffing is the easy part - parsing or generating is the difficult one |
17:31:10 | r-ku | Araq: check out https://github.com/r-ku/Nim/commit/d9df1347e69a5fdb4dd4ce5b53f1cca6a5bcbdf4 and https://github.com/r-ku/Nim/commit/f7b7893d8fa1b8c4149a6d9ec142dd04b79afe80 and comment |
17:31:21 | * | zephyz joined #nim |
17:31:38 | * | bogen-work quit (Quit: leaving) |
17:37:27 | drewsrem | Demos, xcb, xcb_wait_for_event, which expects me to free it, some reason it crashes Valgrind if I do, but it seems to run okay |
17:37:49 | drewsrem | is free in Nim different from stdlib free? |
17:39:00 | Demos | hm, I don't know |
17:39:04 | Demos | it very well could be |
17:39:10 | r-ku | oh score. its so awesome when code that was written without any testing works on first try \o/ (coroutines on windows x64) |
17:40:42 | drewsrem | ah, no it isn't, so I'm pretty lost |
17:46:08 | Demos | valgrind can be strange |
17:46:14 | Demos | try with -gc:bohem |
17:46:16 | Demos | ? |
17:46:30 | Demos | or one of the other simpler GC options |
17:47:01 | drewsrem | Demos, it only happens when I free the ptr tho, the GC shouldn't do anything? - I'm isolating it as much as I can now |
17:47:29 | Demos | right but if the GC is running maybe it triggers strange stuff in valgrind |
17:47:31 | Demos | I don't know |
17:47:45 | EXetoC | *boehm |
17:47:51 | Demos | thanks EXetoC |
17:48:49 | drewsrem | Demos, nope, still crashes |
17:52:30 | * | sparrk joined #nim |
17:55:53 | drewsrem | it's essentially this: http://ix.io/jLL |
17:58:01 | Demos | please try and avoid {.header.} |
17:58:18 | zaspard | Is there anything that prevents me from doing something along the lines of `var observed_tables = initTable[string, Table]()` |
17:58:21 | Demos | but that's not the problem |
18:00:45 | drewsrem | whoops |
18:00:53 | drewsrem | it works now, let me try to find out why :) |
18:01:27 | drewsrem | okay, so free is not stdlib free |
18:01:58 | drewsrem | It works with: http://ix.io/jLM |
18:02:59 | drewsrem | Demos, fixed |
18:03:03 | zaspard | Figured it out, you need to type the nested table. |
18:05:30 | * | Onward_Euler quit (Ping timeout: 240 seconds) |
18:07:16 | Demos | that must be wrapped someplace already |
18:07:34 | Demos | also you probably don't need header for that |
18:07:38 | drewsrem | Demos, I thought so too, it is in lib/system/ansi_c as c_free but it's not exported |
18:07:53 | drewsrem | Demos, why shouldn't I use header? |
18:08:04 | Demos | because there's no need |
18:08:09 | Demos | and in can cause strange namespace issues |
18:08:20 | Demos | the lib that free's in will be linked one way or another |
18:08:38 | Demos | and the importc will ensure the right call is generated |
18:09:13 | drewsrem | but that's because stdlib is always linked? |
18:09:24 | drewsrem | ./lib/system/ansi_c.nim:proc c_free(p: pointer) {.importc: "free", header: "<stdlib.h>".} |
18:09:26 | drewsrem | Nim does it too :P |
18:09:54 | * | gmpreussner|work quit (Read error: Connection reset by peer) |
18:10:44 | * | gmpreussner|work joined #nim |
18:12:23 | drewsrem | Demos, can you tell me about the namespace issues? |
18:12:45 | drewsrem | Nim manual also makes use of header-pragma, should this be changed? |
18:12:49 | drewsrem | I just copied what I saw really |
18:15:42 | drewsrem | Can I now comfortably wrap this ptr into a ref, tell it to call this stdfree-proc I imported and pass it around? |
18:16:51 | Demos | drewsrem: yeah I know, I'm the one adding the warning but I got super busy and I can't exactly deal with the pr while at work :D |
18:17:42 | drewsrem | Demos, oh, sure |
18:18:52 | * | vasher_ quit (Quit: Connection closed for inactivity) |
18:20:53 | * | strcmp1 joined #nim |
18:40:39 | * | brson quit (Remote host closed the connection) |
18:44:17 | baabelfish | I got to say this language is great |
18:46:53 | baabelfish | Araq: what kind of language background do you have? |
18:46:56 | Demos | baabelfish: I know right! It's all in the details |
18:47:13 | Demos | and our bdfl has excellent taste |
18:47:31 | baabelfish | This fills my c++ tmp cravings so well |
18:47:59 | * | doxavore joined #nim |
18:49:18 | baabelfish | Build system of D, erase of js or python safety of c++ at least |
18:49:23 | * | sparrk quit (Read error: No route to host) |
18:49:26 | baabelfish | Ease* |
18:50:55 | * | elbow_jason joined #nim |
18:53:50 | Demos | yeah, it definitely feels like there's way less friction in nim, I can opt into features as I grow my project |
18:55:06 | * | wtw joined #nim |
19:21:47 | * | polde quit (Ping timeout: 240 seconds) |
19:29:31 | * | filcuc quit (Ping timeout: 256 seconds) |
19:31:23 | * | xcombelle quit (Remote host closed the connection) |
19:31:50 | drewsrem | Is it discouraged to use define your own exceptions as "ref objects of Exceptions" and then raise them via constructor "raise MyRefObjException(msg: "my error message")" ? |
19:32:09 | drewsrem | instead of using this awkward newException template |
19:33:02 | drewsrem | I'm trying to use exceptions that carry additional fields beyond the msg-field and newException clearly isn't suited for that, or is this bad practice? |
19:40:43 | EXetoC | maybe newException was added before ref could be applied to types. not using newException is fine imo |
19:42:00 | EXetoC | newFoo is the convention for ref constructors, and initFoo is the convention for value types |
19:42:35 | EXetoC | I usually define a "fail" proc which takes a msg parameter and possibly other parameters as well |
19:43:17 | drewsrem | EXetoC, a fail proc? |
19:43:44 | * | sparrk joined #nim |
19:46:36 | EXetoC | just a proc which raises the exception type defined in the current module. that might not be a good idea though because more types might appear later |
19:47:46 | zaspard | I'm having trouble with nesting sets into a table. Is this something that others have done, or is it currently broken like nested Tables ( https://github.com/nim-lang/Nim/issues/2722 ) |
19:47:47 | drewsrem | EXetoC, gotcha, thanks |
19:48:31 | * | X67r joined #nim |
19:49:40 | EXetoC | I like the "exception + error code" approach though |
19:50:00 | * | nande joined #nim |
19:52:59 | Demos | I like exceptions and sometimes error codes |
19:53:11 | Demos | usually I just want my app to crash when smthing goes wrong |
19:55:39 | drewsrem | hmmm... the _ as a placeholder for tuples seems quite restricted? - I can only do "var _, foo = bar()" but of course if I want to do the same thing again I can't because I'd redefine foo, but when I drop the var and just do an assignment "_, foo = bar()" the placeholder errors out as not valid syntax |
19:56:52 | drewsrem | ah whoops, this isn't Go and Nim doesn't have placeholders like that |
19:57:05 | drewsrem | For some reason I thought it did ... |
19:57:50 | EXetoC | _ can be used for that |
19:59:11 | drewsrem | EXetoC, then I currently can't construct a tuple: http://ix.io/jLV |
19:59:16 | EXetoC | but don't you need parentheses? |
19:59:33 | drewsrem | ah |
19:59:47 | drewsrem | thanks, that was it |
19:59:48 | EXetoC | not according to your snippet |
20:00:03 | EXetoC | it doesn't actually compile? |
20:00:07 | drewsrem | it does |
20:00:17 | drewsrem | it's supposed to be "var (_, p) = bar()" |
20:01:10 | * | dom96_ joined #nim |
20:02:02 | EXetoC | right |
20:02:24 | EXetoC | I don't really care for that "var x, y = 1" syntax |
20:02:27 | drewsrem | but I still can't reassign it / do it more then once: http://ix.io/jLW |
20:03:52 | dom96_ | 'var foo' is not valid syntax |
20:04:03 | drewsrem | ... |
20:04:14 | EXetoC | drewsrem: it has been requested |
20:04:29 | drewsrem | dom96_, that changes the error to "undeclared identifier: '_'" |
20:05:19 | drewsrem | EXetoC, ah that makes sense |
20:05:49 | dom96_ | drewsrem: bug report |
20:06:05 | EXetoC | https://github.com/nim-lang/Nim/issues/2421 |
20:10:02 | * | wuehlmaus quit (Quit: Lost terminal) |
20:11:11 | drewsrem | It would then be nice if a proc returning a tuple could know if the caller actually cares for each element in the tuple and optimize accordingly, i.e. if the caller doesn't care an error field, the proc does no error checking etc., but IIRC the type-system wouldn't allow for that? |
20:11:34 | drewsrem | I guess it's not really a type-system issue |
20:16:27 | * | wuehlmaus joined #nim |
20:20:58 | * | Trustable quit (Remote host closed the connection) |
20:21:00 | federico3 | Demos: this thread is what I was looking for :) http://forum.nim-lang.org/t/1443 |
20:22:59 | * | raza quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) |
20:27:14 | Varriount | Araq: Finally, the MSDN Scraper is finished |
20:29:41 | EXetoC | what's it for exactly? |
20:30:59 | Araq | drewsrem: that can be done with a TR macro |
20:32:30 | drewsrem | Araq, oh nice, I'll look into it |
20:36:20 | drewsrem | Araq, I saw just now that proc free in lib/system isn't the same as c's free from stdlib and I had some issues because I thought it was (Using system-free crashed Vallgrind). Is this expected or have I maybe found a bug? |
20:37:33 | Araq | the free in the stdlib isn't even called "free". why do you think that is? |
20:38:04 | drewsrem | In Nim? |
20:38:43 | Araq | wait a sec |
20:38:50 | Araq | we do have system.free? wtf? |
20:38:51 | EXetoC | there is a free now. I dunno if I added that |
20:38:56 | drewsrem | ./lib/system.nim: proc free*[T](p: ptr T) {.inline, benign.} = |
20:39:14 | Araq | yeah, well that's an oversight, we need to rename this asap |
20:39:17 | EXetoC | when I added the other procs related to memory management (typed overloads) |
20:39:50 | Araq | yeah, I remember |
20:39:56 | EXetoC | in what way does it differ? or is it simply implementation defined? |
20:40:11 | drewsrem | It just uses dealloc I think |
20:40:18 | Araq | well it doesn't use C's memory manager, it uses dealloc |
20:41:47 | drewsrem | That messed me up good today, when things have the same name but are different |
20:42:07 | drewsrem | But shouldn't there be a cfree or something that just importc's free? |
20:42:20 | EXetoC | I think it was because "ptr T" is implicitly converted to "pointer", or whatever the issue was |
20:48:56 | EXetoC | but overloading was involved too. I don't think I created an issue for that |
20:49:30 | drewsrem | Is there an easy way to "make" a ptr into a ref, define my own destructor and pass it around? |
20:56:32 | Araq | drewsrem: no, you need to start with a 'ref' and pass it as a ptr to C-land |
20:56:49 | Araq | so that it has a proper GC header etc |
20:57:49 | drewsrem | I see |
20:58:12 | * | jszymanski quit (Quit: computer sleeps...) |
20:59:43 | * | polde joined #nim |
21:03:19 | * | Matthias247 joined #nim |
21:05:29 | sparrk | How does one handle the general case of using functions from an inherited type? For example, I defined my own seq and now I want to use the .add proc, but instead it give me the error `Error: type mismatch: got (seq[FieldType], FieldType)\nbut expected one of:\nsystem.add(x: var seq[T], y: T)` (snipped) |
21:05:34 | Varriount | Araq: My goodness... There's over a thousand output files. |
21:06:04 | Varriount | sparrk: How did you define your own sequence? |
21:06:44 | sparrk | var field_types: seq[FieldType] # and below: field_types = @[] |
21:07:37 | Varriount | sparrk: Uh, that should work. Could you post your code on gist or some other paste website? |
21:07:40 | EXetoC | is it a "var" in your code? |
21:08:00 | EXetoC | and it's an instantiation rather than inheritance |
21:14:22 | * | Varriount quit (Ping timeout: 248 seconds) |
21:16:37 | * | polde quit (Ping timeout: 256 seconds) |
21:18:43 | sparrk | Varriount: sorry for the delay / poor code quality. I'm still in my first couple days of learning Nim http://paste.ofcode.org/TqQTwnYnzj3yRX3iDYKZXs |
21:22:08 | EXetoC | it's not a sequence so it can't work |
21:22:13 | * | Demos_ joined #nim |
21:22:42 | EXetoC | but you can define an overload of add for your type |
21:25:32 | sparrk | What is not a sequence? field_types? |
21:25:50 | * | Demos quit (Ping timeout: 264 seconds) |
21:26:06 | sparrk | How does one make a sequence of objects and get all the normal sequence procs to work then? |
21:28:09 | EXetoC | seq is a generic type that expects a type parameter, which corresponds to the element type, so seq[SomeElemType] is what you want |
21:28:43 | EXetoC | .eval |
21:30:00 | EXetoC | https://nim-by-example.github.io/seqs/ |
21:31:35 | EXetoC | type annotations would be nice to have in tutorials, but "a" is of type seq[int] |
21:32:05 | EXetoC | just that it has been omitted in that example. "var a: seq[int] = @[1, 2, 3]" works too |
21:38:00 | sparrk | Ah, so I understood that for types outside of the parameter section of the proc |
21:38:16 | EXetoC | and then you can do "a.add(1)", but "a.add('b')" will of course not work |
21:38:18 | sparrk | but it didn't occur to me to use var seq[MyType] |
21:38:31 | sparrk | in the parameters list |
21:38:48 | sparrk | Thank you very much for your help. |
21:40:46 | EXetoC | the signature can be found in the documentation for the system module, if you want to know why it works like that |
21:41:56 | EXetoC | np |
21:48:19 | * | Ven joined #nim |
21:52:39 | * | Ven quit (Ping timeout: 246 seconds) |
22:03:34 | * | Demos_ quit (Remote host closed the connection) |
22:07:49 | * | Demos joined #nim |
22:10:30 | * | sparrk quit (Quit: Leaving) |
22:24:31 | * | Demos quit (Remote host closed the connection) |
22:24:49 | * | mt_laptop joined #nim |
22:28:16 | * | brson joined #nim |
22:31:17 | * | Jesin joined #nim |
22:31:35 | * | mt_desktop joined #nim |
22:37:46 | * | gyeates joined #nim |
22:44:26 | * | Matthias247 quit (Read error: Connection reset by peer) |
23:03:38 | * | elbow_jason quit (Remote host closed the connection) |
23:11:30 | * | gyeates quit (Ping timeout: 246 seconds) |
23:19:08 | * | bjz quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
23:23:12 | * | gyeates joined #nim |
23:32:07 | * | doxavore quit (Quit: I said good day, sir.) |
23:37:27 | * | doxavore joined #nim |
23:53:55 | * | Jesin quit (Quit: Leaving) |
23:55:50 | * | vendethiel quit (Ping timeout: 260 seconds) |