00:03:39 | * | xet7 quit (Quit: Leaving) |
00:05:54 | * | girvo joined #nim |
00:09:53 | * | jsgrant_ quit (Quit: Peace Peeps. o/ If you need me asap, message me at msg[(at)]jsgrant.io & I'll try to get back to you within 24-36 hours.) |
00:10:37 | * | girvo quit (Ping timeout: 255 seconds) |
00:12:19 | * | krux02 quit (Remote host closed the connection) |
00:19:49 | * | krux02 joined #nim |
00:38:58 | * | krux02 quit (Remote host closed the connection) |
00:39:16 | * | krux02 joined #nim |
00:50:36 | * | krux02 quit (Remote host closed the connection) |
00:51:48 | * | demi- quit (Quit: Server shutdown in 3... 2... 1...) |
00:53:52 | * | skrylar joined #nim |
00:55:46 | * | demi- joined #nim |
01:03:58 | * | skrylar quit (Quit: My iMac has gone to sleep. ZZZzzz…) |
01:05:26 | * | skrylar joined #nim |
01:06:42 | * | girvo joined #nim |
01:11:45 | * | girvo quit (Ping timeout: 268 seconds) |
01:20:17 | * | girvo joined #nim |
01:22:40 | * | chemist69 quit (Disconnected by services) |
01:22:45 | * | chemist69_ joined #nim |
01:26:30 | * | Snircle quit (Quit: Textual IRC Client: www.textualapp.com) |
01:32:52 | * | girvo quit (Quit: leaving) |
01:37:38 | * | smt joined #nim |
01:40:07 | FromGitter | <zacharycarter> (https://files.gitter.im/nim-lang/Nim/J8wJ/Screen-Shot-2017-07-13-at-9.39.42-PM.png) |
01:40:13 | FromGitter | <zacharycarter> impossible to tell but that cube is rendered with a 3d perspective |
01:40:25 | FromGitter | <zacharycarter> so mixing 2d and 3d is now possible with zengine :D |
01:41:03 | FromGitter | <zacharycarter> and the code is as simple as |
01:41:28 | FromGitter | <zacharycarter> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=59682148f5b3458e30450db9] |
01:57:11 | * | skrylar quit (Read error: Connection reset by peer) |
02:02:28 | * | def-pri-pub joined #nim |
02:05:45 | * | pilne quit (Quit: Quitting!) |
02:40:30 | demi- | how do i force nim to use a specific C compiler? |
02:40:43 | demi- | i'm on ubuntu and want to use clang instead of gcc |
02:53:38 | * | Jesin quit (Quit: Leaving) |
02:56:35 | FromGitter | <zacharycarter> (https://files.gitter.im/nim-lang/Nim/0hDv/Screen-Shot-2017-07-13-at-10.55.23-PM.png) |
02:57:00 | FromGitter | <zacharycarter> better picture: |
02:57:11 | * | Jesin joined #nim |
02:58:41 | FromGitter | <zacharycarter> demi: https://forum.nim-lang.org/t/2991 |
02:58:47 | FromGitter | <zacharycarter> I know it's not specific to your use case |
02:59:00 | FromGitter | <zacharycarter> but I think there they specify the emscripten compiler |
02:59:04 | FromGitter | <zacharycarter> when clang is supposed to be invoked |
02:59:26 | FromGitter | <zacharycarter> so I think just cc=clang |
04:00:01 | * | def-pri-pub quit (Quit: leaving) |
04:50:56 | * | vendethiel joined #nim |
05:06:19 | * | eldiz quit (Quit: Leaving) |
05:30:03 | * | Vladar joined #nim |
05:51:19 | * | vendethiel- joined #nim |
05:52:04 | * | vendethiel quit (Ping timeout: 246 seconds) |
06:00:01 | * | vendethiel- quit (Ping timeout: 248 seconds) |
06:06:01 | FromGitter | <shalabhc> hi all |
06:06:23 | FromGitter | <shalabhc> what's new with nim these days? getting closer to 1.0? |
06:10:57 | * | ShalokShalom joined #nim |
06:20:55 | * | chemist69_ quit (Ping timeout: 255 seconds) |
06:23:34 | * | chemist69 joined #nim |
06:29:26 | * | skrylar joined #nim |
06:30:25 | FromGitter | <shalabhc> since nim imports all symbols into the module namespace, is there a way to find where a symbol came from? |
06:30:31 | FromGitter | <shalabhc> i'm asking for go-to-definition |
06:31:29 | Araq | use an editor with nimsuggest support |
06:32:35 | FromGitter | <shalabhc> ah nimsuggest - that's what i wanted |
06:36:48 | * | nsf joined #nim |
06:41:11 | FromGitter | <shalabhc> stupid q: why does nimsuggest use a custom format rather than something like json which is easily parsed from most languages? |
06:43:22 | skrylar | wouldn't json be overkill for what is basically an auto-complete helper |
06:43:40 | FromGitter | <Varriount> @shalabhc Because that's what the writer, araq, decided upon. |
06:44:13 | FromGitter | <Varriount> I personally would prefer something more structured, but it works out fairly well. |
06:44:29 | Araq | actually with --epc it uses the format emacs decided upon |
06:44:56 | Araq | the native format is easier to parse than JSON btw, split by \t |
06:45:09 | FromGitter | <shalabhc> skrylar: i don't think so. for the amount of data we are talking about json or tab separated should make no difference |
06:45:43 | FromGitter | <shalabhc> yeah i guess it's trivial to split by \t, but with these custom formats i always wonder if there's a corner case. e.g. are there continuation lines? etc. |
06:46:17 | FromGitter | <shalabhc> I'm not familiar with the emacs format. |
06:48:06 | FromGitter | <shalabhc> would adding json support to nimsuggest be an acceptable PR? |
06:50:55 | skrylar | well, separate by null |
06:51:02 | skrylar | \0 should never appear in code |
06:51:38 | skrylar | it costs less than parsing quotes and escapes although people probably don't care |
06:56:15 | FromGitter | <shalabhc> these days you have editors running on top of the browser stack folks.. yes people probably don't care.. |
06:56:59 | Araq | shalabhc: if the PR comes with tests I don't mind |
06:58:07 | Araq | and when you patch the nimsuggest it will teach you the design decisions by me are not by an idiot, the tab separated format has lots of advantages |
06:58:08 | FromGitter | <shalabhc> ok |
06:58:57 | FromGitter | <shalabhc> yeah i don't doubt tab separated is fine if done thoughtfully |
06:59:01 | Araq | varriount: I have an "immutable strings" branch but it crashes ... |
07:00:51 | Araq | but the theory behind it seems solid and it might improve performance/the language design |
07:01:08 | * | Sentreen quit (Ping timeout: 240 seconds) |
07:01:28 | FromGitter | <shalabhc> for immutable strings from me, mostly coming from python |
07:01:38 | * | arnetheduck joined #nim |
07:03:17 | FromGitter | <shalabhc> but python doesn't have views into strings as a common thing - that would be super useful too, and better when trying to squeeze out performance. |
07:03:32 | FromGitter | <shalabhc> python slices are full copies of the string segments. |
07:06:45 | FromGitter | <shalabhc> everytime i look at nim i'm impressed by the clarity in syntax for most things |
07:08:35 | * | yglukhov joined #nim |
07:11:29 | Araq | I'm only interested in immutable strings for their performance characteristics |
07:11:52 | Araq | since I finally found a design with 0 copies from StringBuilder to string |
07:12:16 | FromGitter | <shalabhc> nice |
07:12:24 | Araq | zero copy slices are still not supported but could work too |
07:12:36 | Araq | but as I said, for now everything crashes and burns |
07:12:40 | FromGitter | <shalabhc> how though? then you cant use the original stringbuilder anymore? |
07:12:59 | Araq | the string builder has a "was moved" flag |
07:13:14 | Araq | if it was moved, it needs to create a fresh buffer |
07:13:31 | FromGitter | <shalabhc> so it's a runtime check? |
07:13:35 | Araq | yes |
07:13:50 | FromGitter | <shalabhc> sounds like copy-on-write |
07:14:09 | Araq | yup, but worse since it's a one bit reference counter |
07:14:19 | * | Sentreen joined #nim |
07:14:47 | Araq | but full COW would require far more codegen/language changes |
07:16:06 | FromGitter | <shalabhc> was_moved bit sounds practical, which is great |
07:17:48 | FromGitter | <shalabhc> what about zero copy concatenation? |
07:18:14 | FromGitter | <shalabhc> i.e. basically a string ref array which behaves like a string |
07:18:55 | FromGitter | <shalabhc> the thing with strings is - sometimes you want copies, sometimes references, both are faster in different cases |
07:19:31 | FromGitter | <shalabhc> i suppose you could always build these things on top of immutable strings.. |
07:21:30 | * | rokups joined #nim |
07:24:41 | * | v17d joined #nim |
07:24:57 | Araq | I never tried a "zero copy concat" data structure, I tried "ropes" and they suck |
07:28:34 | FromGitter | <shalabhc> well rope is zero copy concat |
07:28:46 | FromGitter | <shalabhc> i don't think zero copy concat is a term that's used |
07:29:50 | FromGitter | <shalabhc> i just meant using a 'flat' rope - basically an array of references. it's a common pattern in Python but you can't treat it as a string until you join it first. |
07:47:48 | * | v17d quit (Remote host closed the connection) |
07:48:35 | * | Sentreen quit (Ping timeout: 240 seconds) |
07:49:15 | * | v17d joined #nim |
07:51:31 | skrylar | ropes are great when you have to do a LOT of patching stuff in |
07:55:01 | Araq | skrylar: they are expensive in the compiler and it is stuck with it because the API reflects the implementation |
07:55:53 | skrylar | yeah that's probably a bad usecase then |
07:56:10 | skrylar | i've seen them worth it for text editors that constantly need to change to random edit points |
07:56:17 | skrylar | then they compete with gap buffers |
07:56:23 | skrylar | otherwise .. gap buffers seem good enough? |
07:57:35 | * | Arrrr joined #nim |
08:01:14 | * | Sentreen joined #nim |
08:02:15 | Araq | gap buffer is what I used for NimEdit, yeah |
08:02:44 | FromGitter | <shalabhc> i think rope is pointless these days for editors |
08:03:09 | FromGitter | <shalabhc> copying small snippets of text is so fast |
08:03:37 | FromGitter | <shalabhc> rope will also have suboptimal allocation pattern of actual data |
08:03:46 | FromGitter | <shalabhc> we use a gap buffer too in our editor called Howl |
08:10:40 | Araq | shalabhc: seq[string] would probably be the best idea for Nim's codegen, yes. interop with strings is not important, it's only dumped to disk eventually |
08:11:00 | * | GustavoLapasta joined #nim |
08:11:03 | * | GustavoLapasta quit (Remote host closed the connection) |
08:12:09 | FromGitter | <shalabhc> yeah in that case seq[string] seems good. |
08:15:42 | * | couven92 joined #nim |
08:26:23 | * | adeohluwa joined #nim |
08:26:42 | * | adeohluwa quit (Client Quit) |
08:29:23 | * | adeohluwa joined #nim |
09:17:13 | * | gokr joined #nim |
09:19:18 | skrylar | hrmm |
09:19:31 | skrylar | libui dev had an awkward point about how toolbars are weird on different platforms |
09:20:33 | skrylar | macOS only allows one. Windows allows multiple, as does GTK. But people on Windows nowadays want ribbons, and you have to either 1) be MFC or 2) duplicate them yourself or 3) use winapis that require loading the ribbon from a windows resource |
09:23:21 | Araq | the API is weird too because of this iirc |
09:24:42 | Araq | I still think detaching the menu from the window and to make it share pixels with every other app is a design flaw |
09:25:07 | Araq | and I doubt any serious "usability study" would support any such nonsense |
09:25:33 | Araq | but *shrug*, it's from Apple so it must be good |
09:30:31 | skrylar | it does have advantages but most people don't care about them |
09:32:21 | skrylar | it prevents multiple windows in the same app from having separate menus (which creates confusion), it saves pixels, it creates an expectation that the controls are always in the same place, and the Fitts difficulty index for moving the cursor to the menu is infinite because you can throw the cursor upward and always reach it |
09:33:01 | skrylar | it's also not just Apple. Commodore C64, Amiga, and Atari GEM also did it |
09:33:35 | skrylar | well, c64 had a shell |
09:33:43 | skrylar | amiga and gem did it though, not sure about aamstrad |
09:36:21 | skrylar | they have metrics for navigating from one widget to another using the mouse, some UX stuff uses it. but most people don't care if the user's ux is bad |
09:38:41 | Araq | I know about Fitts difficulty index and I disagree anyway :P |
09:40:38 | Araq | it saves pixels by *sharing* pixels between apps, you might as well run every app fullscreen then |
09:40:54 | Araq | or share even more stuff between them, what could possibly go wrong .... |
09:41:26 | * | gokr quit (Ping timeout: 246 seconds) |
09:42:32 | skrylar | how many times are people triggering menu actions across applications |
09:44:19 | skrylar | technically pie menus are also superior to context menus* but nobody cares about those either ._. |
09:45:04 | skrylar | saw a whitepaper on that from the 90s where they were demonstrating that for any context menu with less than ten items at a time, they were objectively superior because they developed activation gestures at the same time they were used, which standard menus don't do |
09:51:35 | * | arnetheduck quit (Ping timeout: 240 seconds) |
09:53:57 | Araq | that's exactly my point. the interface guideline was applied totally arbitrarily IMO, so for menus we have an "optimized" solution but for nothing else and as a result it's only inconsistent and confusing |
09:56:13 | Araq | and top level menus are not even triggered often so why should these get a low Fitt difficulty index |
09:58:52 | * | samuell joined #nim |
10:02:02 | * | gokr joined #nim |
10:05:37 | skrylar | well there's always elementaryos |
10:05:50 | skrylar | they seem to have decided to just jam all the menus for applications under hamburger buttons |
10:06:00 | skrylar | stuck to gtkheaderbars |
10:09:01 | * | vendethiel joined #nim |
10:09:19 | euantor | That's the Gnome 3 way too |
10:09:48 | euantor | Just look at the files app in Gnome 3 and there's so much missing functionality and hidden functionality because they don't want a menu bar |
10:22:02 | * | Arrrr quit (Ping timeout: 246 seconds) |
10:35:13 | * | skrylar quit (Ping timeout: 255 seconds) |
11:05:48 | * | adeohluwa quit (Ping timeout: 260 seconds) |
11:05:50 | * | skrylar joined #nim |
11:11:10 | skrylar | machine learning in nim. |
11:11:19 | skrylar | it's not actually that hard but you do write a lot yourself :x |
11:11:35 | * | skrylar quit (Quit: Textual IRC Client: www.textualapp.com) |
11:29:44 | * | skrylar joined #nim |
11:29:49 | skrylar | delicious ram upgrades |
11:43:00 | skrylar | intrigued by Cells from lisp. thought of a way to make it work in nim, although it's ugly. |
11:43:51 | skrylar | the whole thing with cells is that instead of having changed procs you just say "i depend on that value" and it watches for those changes and calls the procs accordingly |
11:44:01 | skrylar | i don't know that it ever took off in lisp world but it was fascinating |
11:45:53 | skrylar | actually might be able to do it as a macro |
11:56:31 | * | Vi- joined #nim |
12:03:01 | * | Snircle joined #nim |
12:06:42 | * | SunDwarf quit (Read error: Connection reset by peer) |
12:21:56 | skrylar | eh well i wrote a proposal for a menu-making macro. |
12:22:01 | skrylar | will have to post it somewhere readable later |
12:25:28 | * | Vi- quit (Ping timeout: 246 seconds) |
12:28:41 | * | ShalokShalom quit (Remote host closed the connection) |
12:37:02 | * | krux02 joined #nim |
12:37:13 | * | skrylar_ joined #nim |
12:38:47 | krux02 | skrylar: menu-making macro? |
12:39:16 | krux02 | do you mean UI? |
12:39:34 | * | skrylar quit (Quit: My iMac has gone to sleep. ZZZzzz…) |
12:40:51 | krux02 | I did write a UI macro in C++ once, but all it could do was connecting "void fobbar()" procs to buttons [foobar], that's it |
12:50:46 | skrylar_ | krux02, yes. poking around with libui |
12:51:01 | skrylar_ | contemplating macros for i |
12:51:04 | skrylar_ | *it |
12:51:18 | skrylar_ | Red peeps have all the fun with those right now ;p |
12:52:01 | krux02 | well sadly there are no languages at all where UI code is fun :( |
12:52:37 | skrylar_ | kivy has a dsl for it. red and rebol too. |
12:52:48 | krux02 | kivy? |
12:52:56 | krux02 | I know Elm, but that is just the web |
12:53:25 | FromGitter | <ChristianWitts> Kivy is a Python UI Framework https://kivy.org/ |
12:53:41 | krux02 | Ah that's why I don't know it, I don't do pytho |
12:53:43 | krux02 | n |
12:54:29 | * | Vi- joined #nim |
12:55:58 | krux02 | skrylar_: do you have experience with red and rebol? |
12:56:09 | krux02 | sounds like a dinosaur |
12:58:08 | * | user0 quit (Quit: user0) |
13:02:55 | * | Vi- quit (Ping timeout: 246 seconds) |
13:09:02 | krux02 | skrylar_: When you have experience with red. I would really like to know if their claim to be a full stack programming language is true or not. |
13:10:16 | krux02 | full stack for me does not only mean to have low level stuff like C, but also to have abstractions on them that have no runtime overhead like c++ templates or Nim generics |
13:11:34 | skrylar_ | rebol is dead :( |
13:11:42 | skrylar_ | red is alive. priorities are weird. |
13:11:44 | Araq | pretty sure it's not a "full stack" language by that definition, krux02 |
13:12:03 | Araq | also I doubt it has anything that can be called "static typing" |
13:12:28 | skrylar_ | well Red/System is meant to replace C for their use. it has some typing but its pretty weak. has only gotten enough attention to boot itself really |
13:12:34 | skrylar_ | Red is intended to be scripting |
13:12:45 | skrylar_ | you're supposed to write it in red, profile and then move slow stuff down to red/system |
13:13:23 | skrylar_ | this would be great if they would focus one issue to completion. but he's trying to play the venture capital game so it's like, we have this halfass implementation here and this halfass feature there to attract VCs in china |
13:14:37 | skrylar_ | i bothered them about it because it's far easier to find derps like me to fiddle with macros for UI stuff than it is to find garbage collector experts |
13:15:06 | skrylar_ | but they have experts doing drudge work lol |
13:15:52 | skrylar_ | we probably do need to steal parse though |
13:21:04 | subsetpark | Honestly, you gotta figure nim is as close to full-stack as there is out there... |
13:22:52 | skrylar_ | nim is usable. |
13:22:58 | skrylar_ | that's more than red can say :> |
13:23:21 | skrylar_ | eh well parse could probably be done in a macro. it's just a PEG parser engine |
13:23:30 | skrylar_ | makes dsls a lot easier tho |
13:23:33 | tankfeeder | hi |
13:23:38 | skrylar_ | hi tankfeeder |
13:23:41 | tankfeeder | i'm looking example code of seq of tuples |
13:24:53 | skrylar_ | i don't think there's anything special about those? |
13:26:10 | FromGitter | <TiberiumN> yeah |
13:26:17 | FromGitter | <TiberiumN> seq[tuple[a, b: int]] ? |
13:28:06 | tankfeeder | what if a is enum type ? |
13:29:28 | FromGitter | <TiberiumN> ehm |
13:29:30 | FromGitter | <TiberiumN> it works? |
13:29:47 | FromGitter | <TiberiumN> ```type ⏎ A = enum Cab, Bab, Rab ⏎ ⏎ var b: seq[tuple[a: A, b: int]]``` [https://gitter.im/nim-lang/Nim?at=5968c74b89aea4761d9a5569] |
13:29:49 | skrylar_ | (a: SomeValue) |
13:31:15 | tankfeeder | ok |
13:31:30 | tankfeeder | last question: how to add several items to this seq by hands ? |
13:33:36 | skrylar_ | something.append((a: SomeValue)) |
13:33:47 | * | Vi- joined #nim |
13:35:01 | * | gokr quit (Quit: Leaving.) |
13:35:17 | Araq | 'append'? what is this? |
13:35:22 | Araq | Nim uses 'add' |
13:36:38 | * | skrylar_ covers Araq in templates |
13:37:39 | Araq | lol |
13:40:57 | tankfeeder | http://ideone.com/Qfj4XT |
13:41:04 | tankfeeder | tried in different combinations |
13:42:34 | krux02 | tankfeeder: the [...] in the last line is parsed as an array literal |
13:42:39 | krux02 | like [1,2,3,4,5] |
13:42:52 | krux02 | and you can't have an array with different types for each element |
13:43:39 | krux02 | a tuple constructor looks like this (a:Cab, b:12) |
13:44:21 | krux02 | b.add((a:Cab, b:12)) |
13:46:57 | tankfeeder | aaaa |
13:50:33 | tankfeeder | b.add((a:Cab, b:12)) doesnt work |
13:50:46 | tankfeeder | SIGSEGV: Illegal storage access. (Attempt to read from nil?) |
13:53:26 | skrylar_ | seqs have to be initialized |
13:53:44 | skrylar_ | var foof: seq[...] \n newseq(foof) |
13:56:18 | tankfeeder | indeed |
13:56:19 | tankfeeder | works |
14:01:12 | * | couven92 quit (Quit: Client disconnecting) |
14:36:13 | * | yglukhov quit (Remote host closed the connection) |
14:37:27 | subsetpark | by the way, what's the story with static initialization analysis? i seem to recall that they were trying to make it stronger |
14:43:28 | * | skrylar joined #nim |
14:45:47 | * | yglukhov joined #nim |
14:50:14 | * | yglukhov quit (Ping timeout: 255 seconds) |
14:53:50 | * | skrylar quit (Quit: My iMac has gone to sleep. ZZZzzz…) |
15:06:39 | * | Arrrr joined #nim |
15:06:39 | * | Arrrr quit (Changing host) |
15:06:39 | * | Arrrr joined #nim |
15:07:05 | * | Vi- quit (Ping timeout: 240 seconds) |
15:07:44 | * | couven92 joined #nim |
15:15:11 | FromGitter | <Varriount> Araq: The immutable strings.. Will those be a separate data type, or an optimization performed for basic string types? |
15:27:00 | * | Vi- joined #nim |
15:34:29 | * | yglukhov joined #nim |
15:37:28 | FromGitter | <krux02> I don't like that seq need to be initialized. I still hope that some day a seq won't allow the nil value anymore and by default if will be initialized to an empty seq |
15:39:10 | * | yglukhov quit (Ping timeout: 276 seconds) |
15:39:48 | demi- | maybe someone can answer my question from last night: I am on ubuntu and i want my `nim c` commands to use `clang` instead of `gcc`; how do i setup my nim.cfg to make it do this automatically? |
15:51:44 | FromGitter | <zacharycarter> demi-: did you see my answer last night? |
15:52:15 | FromGitter | <zacharycarter> I'm not sure if it was correct or not but I tried answering |
15:53:06 | demi- | zacharycarter, i did not; i rebooted my znc instance at one point so i might have missed it |
15:53:57 | * | yglukhov joined #nim |
16:04:07 | Arrrr | https://github.com/zacharycarter/blt-nim/blob/master/blt.nim#L284 |
16:06:32 | FromGitter | <retsyo> change "cc = gcc" in Nim\config\nim.cfg to "cc = clang" will tell nim to use clang |
16:09:20 | FromGitter | <retsyo> but can we specify command line argument for nim to change compiler? |
16:10:09 | couven92 | @retsyo, `nim compile --cc:clang myMagicNimFile` |
16:13:45 | FromGitter | <retsyo> thanks. it seems that `nim --help` and `nim --advanced` do not show this |
16:15:08 | couven92 | @retsyo, oh, you're right :O I'm certain that it was there once... |
16:15:56 | couven92 | I'll write up a PR for that, so it'll be in the help text again. Right next to --os and --cpu |
16:18:57 | * | atweiden-air joined #nim |
16:20:04 | atweiden-air | can anyone teach me how to avoid blowing up the stack on this: https://github.com/atweiden/scripts/blob/master/get_siacoin_subsidy_at_height.nim#L46 |
16:21:57 | * | skrylar_ quit (Ping timeout: 268 seconds) |
16:27:55 | * | vendethiel quit (Quit: q+) |
16:47:46 | * | atweiden-air quit (Quit: Leaving.) |
17:03:10 | * | Snircle quit (Quit: Textual IRC Client: www.textualapp.com) |
17:05:23 | Araq | atweiden-air: use an explicit stack, recursion elimination is usually not that hard |
17:06:08 | * | chemist69 quit (Ping timeout: 255 seconds) |
17:06:53 | * | chemist69 joined #nim |
17:20:04 | * | Vi- quit (Ping timeout: 260 seconds) |
17:23:56 | Araq | krux02: that's in fact now part of plans to move Nim to v1 |
17:24:22 | Araq | varriount: separate type but binary compatible with string (aka type mutstring = distinct string) |
17:26:26 | Arrrr | Is 'forward object type declarations' still fashion? |
17:28:16 | Araq | what do you mean? |
17:30:42 | * | samuell quit (Quit: Hejdå) |
17:32:44 | Arrrr | https://github.com/nim-lang/Nim/blob/devel/todo.txt#L7-L8 |
17:33:51 | * | cspar quit (Read error: Connection reset by peer) |
17:34:19 | * | cspar joined #nim |
17:38:00 | Araq | yeah we still need to do this |
17:56:59 | krux02 | I don't have problems with forward declarations. I know nim is the only "modern" language to still need them, but the way a file is processed by the compiler in Nim is something and is simple enogh to understand. Especially whith macros that have side effects in static vars |
17:59:01 | * | krux02 quit (Remote host closed the connection) |
17:59:54 | * | Vi- joined #nim |
18:00:53 | * | v17d quit (Ping timeout: 246 seconds) |
18:07:54 | * | Vi- quit (Ping timeout: 255 seconds) |
18:21:12 | * | rokups quit (Quit: Connection closed for inactivity) |
18:21:39 | * | Trustable joined #nim |
18:24:18 | * | smt quit (Read error: Connection reset by peer) |
18:24:23 | * | smt_ joined #nim |
18:24:40 | * | v17d joined #nim |
18:31:46 | * | Vi- joined #nim |
18:34:55 | * | xet7 joined #nim |
18:46:57 | * | v17d quit (Ping timeout: 240 seconds) |
19:07:00 | * | sz0 joined #nim |
19:13:35 | * | Vi- quit (Ping timeout: 240 seconds) |
19:14:56 | * | salewski joined #nim |
19:15:31 | salewski | Trustable, I just saw you name... |
19:16:03 | * | Vladar quit (Ping timeout: 260 seconds) |
19:16:11 | salewski | proc cairo_paint*(cr: pointer) {.importc: "cairo_paint", libgtk3.} |
19:16:15 | * | pilne joined #nim |
19:16:55 | salewski | So you use libgtk3 for all your cairo calls in your NiGui GTK backend? |
19:17:44 | salewski | When that works -- well does that mean that the lib specified has no meaning at all? |
19:18:07 | salewski | Because, cairo is a separate library of course. |
19:19:49 | salewski | Maybe that is true, maybe the importc name in only relevant, and the specified lib is just ignored? |
19:21:51 | * | Ven joined #nim |
19:22:15 | * | Ven is now known as Guest69722 |
19:22:32 | salewski | I saw it in this file recently: https://github.com/trustable-code/NiGui/blob/master/src/nigui/private/gtk3/gtk3.nim |
19:23:48 | * | Guest69722 is now known as Ven`` |
19:27:21 | Araq | salewski: I think trustable is sloppy with his importcs and gets away thanks to static linking against gtk |
19:27:42 | Araq | or at least static linking against the shared objects |
19:29:49 | salewski | OK, thanks. |
19:32:16 | Trustable | salewski, it works so far, I don't know exactly why |
19:35:35 | salewski | OK. I think Araq has given the explanation. |
19:36:26 | * | salewski quit (Quit: WeeChat 1.4) |
19:38:14 | * | v17d joined #nim |
19:39:22 | * | v17d quit (Remote host closed the connection) |
19:44:05 | * | ShalokShalom joined #nim |
19:50:59 | * | Vi- joined #nim |
19:55:06 | Demos[m] | glib just merged meson |
19:55:08 | Demos[m] | !! |
19:55:35 | * | andrzejku joined #nim |
19:55:38 | andrzejku | hello |
19:55:52 | andrzejku | I need to ask something important |
19:56:06 | * | nsf quit (Quit: WeeChat 1.7.1) |
20:05:28 | FromGitter | <Varriount> Ask away |
20:07:37 | andrzejku | Can we use NimQtPlugin as template for our plugin? |
20:10:32 | FromGitter | <Varriount> andrzejku: What's NimQtPlugin? |
20:10:49 | andrzejku | plugin to write in qt |
20:11:07 | andrzejku | for nim |
20:11:47 | FromGitter | <Varriount> You mean https://github.com/filcuc/NimQtCreatorPlugin ? |
20:12:38 | * | ShalokShalom quit (Ping timeout: 260 seconds) |
20:12:45 | andrzejku | yes |
20:13:48 | FromGitter | <Varriount> I'd file an issue in the project or try contacting filcuc then. |
20:14:27 | FromGitter | <Varriount> Demos[m]: The build system? |
20:15:24 | * | Arrrr quit (Read error: Connection reset by peer) |
20:21:00 | * | Ven`` quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
20:22:30 | * | Ven joined #nim |
20:22:53 | * | Ven is now known as Guest79280 |
20:23:34 | dom96 | andrzejku: https://github.com/filcuc/NimQtCreatorPlugin/blob/master/LICENSE |
20:23:36 | dom96 | Yes you can |
20:26:12 | Demos[m] | yeah glib just merged the switch to meson from autotools |
20:26:37 | Demos[m] | I think gtk has already done that |
20:27:13 | * | Guest79280 quit (Ping timeout: 260 seconds) |
20:40:04 | * | Ven_ joined #nim |
21:06:21 | * | pilne quit (Quit: Quitting!) |
21:08:38 | Vi- | huh, I assumed the case statement was an expression |
21:09:06 | Vi- | https://i.gyazo.com/30fd5c755bd49a899f3f105723012f7d.png |
21:09:22 | Vi- | This could have been shorter |
21:12:01 | * | Ven_ quit (Ping timeout: 248 seconds) |
21:12:33 | dom96 | pretty sure it is |
21:14:53 | Vi- | "expression 'case yadayada' has no type (or is ambigious)" |
21:15:35 | Vi- | or is it because I throw an exception on the default case? |
21:16:49 | Vi- | Hmm... looks like it |
21:17:09 | Vi- | Then that error message is pretty misleading |
21:17:58 | Vi- | also that it can't figure out the return type if the default case is missing (or void) |
21:19:37 | euantor | Cases have to cover all possible values, so you need to have a default, and you need to initialise the variable if you're in an assignment context |
21:19:42 | dom96 | yep, error messages can always be improved |
21:19:44 | euantor | Makes sense to me |
21:20:01 | euantor | The error message could be improved as you say, but the rule is sound |
21:20:40 | Vi- | euantor, sure but the default case is a throw |
21:20:53 | Vi- | Shouldnt matter if the variable is initialized there or not |
21:20:57 | euantor | Yeah, and you can't assign a throw to a variable |
21:21:09 | Vi- | And it doesnt have to since its a throw |
21:21:12 | euantor | If you're in an assignment context (x = y), you need to assign a type |
21:21:16 | Vi- | I'm not certain but I think this works pretty well in scala |
21:21:44 | euantor | I've never used scala, but the current rules make sense to me coming from a language where things like this are impossible (C#) |
21:22:28 | Vi- | euantor, its like the return value of a function, when you throw you dont need a return value |
21:24:39 | Vi- | Yea this works in scala. Granted, it doesnt force me to add a default branch |
21:25:30 | Vi- | Still, if I have a throw there the intent is fairly obvious and it should be able to deduce the correct type, imo |
21:26:31 | dom96 | The language could use the default value for the inferred type |
21:26:43 | dom96 | I'm sure that isn't as easy as it sounds though |
21:26:47 | euantor | I'm not so sure, I like the current rules personally. Makes it easier to reason about. |
21:26:50 | dom96 | A better error message would be enough for now. |
21:27:17 | * | chemist69 quit (Ping timeout: 258 seconds) |
21:27:19 | Vi- | dom96, I feel like thats what it does and thats why it cant deduce the type |
21:27:24 | euantor | Default value might become more difficult when it comes to reference types - the value would then be null if the case doesn't match |
21:27:34 | Vi- | Doesnt look very intentional to me, I guess I'll create an issue |
21:27:40 | euantor | Which might lead to error |
21:28:21 | * | chemist69 joined #nim |
21:36:37 | Vi- | https://github.com/nim-lang/Nim/issues/6101 < There, in case you want to comment |
21:44:40 | * | nsf joined #nim |
21:49:43 | * | couven92 quit (Ping timeout: 255 seconds) |
22:02:14 | * | Ven joined #nim |
22:02:38 | * | Ven is now known as Guest24175 |
22:03:03 | * | couven92 joined #nim |
22:06:09 | * | v17d joined #nim |
22:16:08 | * | Calinou quit (Remote host closed the connection) |
22:22:27 | * | yglukhov quit (Read error: Connection reset by peer) |
22:22:52 | * | Calinou joined #nim |
22:23:00 | * | yglukhov joined #nim |
22:38:18 | * | Trustable quit (Remote host closed the connection) |
22:47:41 | * | v17d quit (Remote host closed the connection) |
22:49:22 | * | v17d joined #nim |
22:57:23 | * | smt_ quit (Read error: Connection reset by peer) |
22:57:32 | * | smt__ joined #nim |
23:01:26 | * | andrzejku quit (Quit: Textual IRC Client: www.textualapp.com) |
23:05:39 | * | Calinou quit (Remote host closed the connection) |
23:12:33 | * | Calinou joined #nim |
23:19:14 | * | couven92 quit (Quit: Client Disconnecting) |
23:23:37 | yglukhov | dom96: are you around? |
23:23:55 | dom96 | yes, but super tired :) |
23:24:48 | yglukhov | yeah, same. well i hope my question is easy ;) what's the status of upcoming asyncdispatch? |
23:43:53 | FromGitter | <watzon> Hey everyone! I'm new here so expect lots of questions |
23:45:44 | FromGitter | <watzon> Is anyone here familiar with NimYAML? |
23:50:57 | * | skrylar_ joined #nim |