<< 05-04-2018 >>
00:12:47*zolk3ri joined #nim
00:40:09*leorize quit (Ping timeout: 265 seconds)
00:42:08*zolk3ri_ joined #nim
00:43:11*leorize joined #nim
00:46:03*Zevv_ joined #nim
00:46:07*nuxdie_ joined #nim
00:46:26*floppydh_ joined #nim
00:46:31*jxy_ joined #nim
00:48:21*shodan45_ joined #nim
00:49:18*pigmej_ joined #nim
00:49:45*kunev_ joined #nim
00:49:53*byte512_ joined #nim
00:50:00*beatmox_ joined #nim
00:51:11*kunev- joined #nim
00:51:14*floppydh quit (*.net *.split)
00:51:14*zolk3ri quit (*.net *.split)
00:51:14*beatmox quit (*.net *.split)
00:51:14*byte512 quit (*.net *.split)
00:51:14*kunev quit (*.net *.split)
00:51:15*jxy quit (*.net *.split)
00:51:15*nuxdie quit (*.net *.split)
00:51:15*Amun_Ra quit (*.net *.split)
00:51:15*Zevv quit (*.net *.split)
00:51:16*shodan45 quit (*.net *.split)
00:51:16*pigmej quit (*.net *.split)
00:51:16*beatmox_ is now known as beatmox
00:51:19*pigmej_ is now known as pigmej
00:51:35*martinium joined #nim
00:51:51FromGitter<gogolxdong> Is there anyone working on browser?
00:52:21martiniumglad to see that nim is part of the official fedora repos
00:52:45FromGitter<gogolxdong> yes, it's a good news.
00:53:58*craigger quit (Ping timeout: 240 seconds)
00:54:04*zolk3ri_ quit (Remote host closed the connection)
00:55:03*kunev_ quit (Ping timeout: 255 seconds)
00:56:24*craigger joined #nim
00:58:37*Amun_Ra joined #nim
01:10:09*martinium quit (Ping timeout: 260 seconds)
01:10:11*S1t1Schu joined #nim
01:12:02*martinium joined #nim
01:14:10*S1tiSchu quit (Ping timeout: 264 seconds)
01:16:57*martinium quit (Ping timeout: 240 seconds)
01:19:20*martinium joined #nim
01:48:32*martinium quit (Quit: WeeChat 2.0.1)
01:51:05*yglukhov joined #nim
01:55:27*yglukhov quit (Ping timeout: 240 seconds)
02:08:46*endragor joined #nim
02:13:48*endragor quit (Ping timeout: 276 seconds)
02:14:54*vlad1777d quit (Ping timeout: 260 seconds)
03:14:55*smt` joined #nim
03:18:41*smt quit (Ping timeout: 265 seconds)
03:22:37*dddddd quit (Remote host closed the connection)
03:29:35FromGitter<Varriount> Araq: What was the motivation behind disallowing "invalid" escape sequences in strings, and making generalized string literals use raw behavior?
03:30:35FromGitter<Varriount> Rather than, say, allowing invalid escape sequences (ignoring them) and not using raw behavior with generalized string literals?
03:35:28FromGitter<Varriount> Or allowing a pragma for use with the functions to mark whether escaping should be done.
03:41:31*rockcavera quit (Read error: Connection reset by peer)
03:42:55*rockcavera joined #nim
04:11:53*endragor joined #nim
04:19:28*Lord_Nightmare quit (Ping timeout: 240 seconds)
04:26:42*Lord_Nightmare joined #nim
04:51:49*leorize quit (Ping timeout: 260 seconds)
05:13:26*smt` quit (Read error: Connection reset by peer)
05:13:36*smt` joined #nim
05:15:49*yglukhov joined #nim
05:20:29*yglukhov quit (Ping timeout: 265 seconds)
05:24:11*nsf joined #nim
05:36:48*Vladar joined #nim
05:54:30*Zevv_ is now known as Zevv
06:00:17*arecaceae joined #nim
06:13:19*leorize joined #nim
06:22:09Araqvarriount: re"\d+" requires escapes to not be interpreted.
06:22:27Araqignoring invalid escape sequences? why?
06:39:44*jaco60 joined #nim
06:50:38*r3d9u11 joined #nim
06:51:51FromGitter<Varriount> Araq: I guess I'm just a bit irritated that the "fmt" function in the strfmt module doesn't just re-escape things.
06:55:00*yglukhov joined #nim
07:00:42*rokups joined #nim
07:06:57Araqyeah, I'm not gonna reply to this
07:09:43Araq&"{foo}\n" is the better syntax ;-)
07:15:08FromGitter<alehander42> @Araq @dom96 what do you think about https://github.com/nim-lang/Nim/issues/7505
07:17:46AraqIMO JS is too different from our usual posix/windows splits we have for the native code
07:18:01Araqtimes.nim with its 'when defined(js)' makes me cringe
07:18:27Araqinstead we should have JS specific overrides for the stdlib modules we end up emulating
07:18:36FromGitter<alehander42> well that's why I had an alternative idea, to just have them in a `node_system` module or something like that (and eventually autoinclude it with `jsffi` for node)
07:18:59Araqthis can easily be done by playing with the default --path
07:19:50AraqI don't see the connection to system.nim though
07:20:00Araqare you talking about sysio?
07:20:06FromGitter<alehander42> ok, I mean more like "system-level stuff"
07:20:09FromGitter<alehander42> not like `system.nim`
07:20:15FromGitter<alehander42> I couldn't find a good word for it
07:21:24FromGitter<alehander42> so, you mean when one imports `ospaths` in nodejs, we will actually load a `node/ospaths.nim` ?
07:23:32Araqyes
07:23:55FromGitter<alehander42> yeah, that makes sense
07:24:26FromGitter<alehander42> and what about the `async` versions, is it ok to also include them in the same node override modules
07:29:53Araqwell they are not node-specific
07:31:44FromGitter<alehander42> hm do we have anything else than `asyncfile` ? what I imagined was more like `async readFile()` `async createDir()` etc
07:39:20Araqyeah asyncfile is underdeveloped
07:39:27*r3d9u11 quit (Ping timeout: 240 seconds)
07:46:07FromGitter<nathandaly> > Nim does not allow silently throwing away a return value a discard must be used, however I found this works? let _ = execCmd...
07:54:24FromGitter<mratsim> you can tag a proc {.discardable.}
07:55:20FromGitter<nathandaly> The docs said it doesn't allow silently throwing away return vars but it didn't throw an error when I did?
07:56:23FromGitter<mratsim> `_` is special and meant for throw away return values, expecially for tuple deconstruction
07:56:56FromGitter<nathandaly> Ah that explains it then thanks :)
07:57:33FromGitter<mratsim> like let (x, _, _) = foo(bar)
08:03:12*sendell joined #nim
08:03:51*athenot quit (Ping timeout: 265 seconds)
08:04:34*gmpreussner quit (Ping timeout: 264 seconds)
08:05:34*gmpreussner joined #nim
08:11:00*planetis[m] quit (Ping timeout: 248 seconds)
08:11:46*zama quit (Ping timeout: 264 seconds)
08:12:12*Tanger quit (Ping timeout: 256 seconds)
08:12:22*riidom_ quit (Ping timeout: 264 seconds)
08:12:22*Sentreen quit (Ping timeout: 264 seconds)
08:12:22*kier quit (Ping timeout: 264 seconds)
08:12:22*joshbaptiste quit (Ping timeout: 264 seconds)
08:13:50*zama joined #nim
08:13:55*Sentreen joined #nim
08:13:56FromGitter<narimiran> hey @mratsim, last night there was some talk about calling python script from nim, and then using the results in nim - have you maybe had similar experience? is there some idiomatic/easy way to do that?
08:14:00*riidom joined #nim
08:14:34*vegax87_ quit (Quit: EliteBNC - http://www.elitebnc.net/)
08:15:12*vegax87 joined #nim
08:15:51FromGitter<mratsim> mmmh, there are calling Nim from Python for sure, calling Python from Nim maybe asks @alehander42 : https://github.com/metacraft-labs/py2nim
08:16:15*kier joined #nim
08:16:30*Tanger joined #nim
08:20:23*zama quit (Ping timeout: 276 seconds)
08:21:15*zama joined #nim
08:21:27*Lord_Nightmare quit (Ping timeout: 240 seconds)
08:22:17*planetis[m] joined #nim
08:22:42*xet7 joined #nim
08:25:21*joshbaptiste joined #nim
08:25:49*pydsigner quit (Ping timeout: 256 seconds)
08:26:30*Lord_Nightmare joined #nim
08:26:52*solitudesf quit (Ping timeout: 245 seconds)
08:26:52*byteflame quit (Ping timeout: 245 seconds)
08:26:53*dyce[m] quit (Ping timeout: 245 seconds)
08:26:58*survivorm[m] quit (Ping timeout: 260 seconds)
08:26:58*TheManiac quit (Ping timeout: 260 seconds)
08:26:58*mgdelacroix[m] quit (Ping timeout: 260 seconds)
08:26:59*unclechu quit (Ping timeout: 260 seconds)
08:28:05FromGitter<narimiran> yeah, there is a video on youtube about calling nim from python (FFI)
08:29:30FromGitter<narimiran> i had an idea to rewrite some python code in nim, and when i need to use `scipy.integrate` (to solve some ODE), to call python to do that work, and then return back to nim....
08:31:05FromGitter<alehander42> actually I think that was one of the ideas of @yglukhov https://github.com/yglukhov/nimpy
08:31:19*TheManiac joined #nim
08:31:29*survivorm[m] joined #nim
08:31:29*solitudesf joined #nim
08:31:54*byteflame joined #nim
08:31:55*mgdelacroix[m] joined #nim
08:32:06*pydsigner joined #nim
08:32:23FromGitter<alehander42> but you have to ask him if the calling python from nim is working
08:32:23FromGitter<alehander42> `py2nim` is more for porting python code to Nim, not calling the Python interpreter
08:32:41FromGitter<alehander42> so in this case you wouldn't be able to call scipy (except if your port it :D )
08:33:21AraqparseJson(execProcess"python stuff.py")
08:35:10*Sentreen quit (Ping timeout: 264 seconds)
08:36:22*unclechu joined #nim
08:36:32*dyce[m] joined #nim
08:37:25FromGitter<narimiran> @alehander42 nimpy looks interesting!
08:37:34*edcragg quit (Ping timeout: 264 seconds)
08:39:33FromGitter<narimiran> @Araq yesterday i have tried to use `execCmdEx`, but `execProcess` might be better for my needs, thanks
08:39:58*Tanger quit (Ping timeout: 264 seconds)
08:41:45*edcragg joined #nim
08:42:26FromGitter<narimiran> what i want from python is numpy.array - yesterday i have printed element by element of that np.array, then manually parsed the received string in nim (`outp.strip.splitLines.map(parseFloat)`)
08:43:05FromGitter<narimiran> JSON might be a nicer way to do it....
08:48:26*Sentreen joined #nim
08:58:31FromGitter<alehander42> why don't we have default `$` for `ref objects`?
08:58:49FromGitter<alehander42> it seems easy to do in the general case (with `..` for recursion)
08:59:13Araqthe $ for objects was already a mistake
08:59:28FromGitter<alehander42> I can't imagine why
09:00:05FromGitter<alehander42> if a type needs special `$`, the author will define it, otherwise having *something* is better than nothing
09:00:49Araqthat's not true, people write hashit($x) to make things compile and then it doesn't work
09:01:56FromGitter<alehander42> well "people do that wrong thing in that particular edge case" doesn't mean "not useful it for all other legit cases"
09:02:28Araqwhen do you use the $ for objects? for debugging.
09:02:35FromGitter<alehander42> exactly
09:02:51Araqonly for debugging, for all other use cases its in a Nim specific format and hardly useful
09:03:04FromGitter<alehander42> well, it's incredibely useful for debugging
09:03:17FromGitter<alehander42> and development (which is where you spend 90% of the time anyway)
09:03:47Araqsure but we should have a 'debug' macro then...
09:03:58Araqwell we have something in future.nim like that
09:04:20FromGitter<alehander42> does it return a string ?
09:04:53FromGitter<alehander42> well I am just a bit afraid of having several similar mechanisms , as `__str__` and `__repr__` in Python (I was never sure which representation would I get sometimes)
09:05:44Araqwell I'm not gonna change it
09:06:50FromGitter<alehander42> hm I see only debugEcho
09:06:58Araqto answer your question
09:07:04Araquse $refobj[]
09:07:33FromGitter<alehander42> yeah I know that, but it's tedious
09:08:19FromGitter<alehander42> and e.g. new users will have no idea that works, and will just write loads of `$` or printing manually fields all the time which will outweight the eventual bugs because of `$` I think
09:08:30FromGitter<alehander42> loads of custom `$` *
09:08:40FromGitter<alehander42> but that's speculation of course :D
09:09:10FromGitter<alehander42> (again, I can have my own `ref $` easily, just wanted to discuss it for the stdlib)
09:13:10FromGitter<alehander42> I admit that actually having some custom general `dumpObj(obj, depth)` which works for recursive objects might be a good compromise
09:42:07*Tanger joined #nim
09:48:35FromGitter<mratsim> @narimiran for Numpy interfacing try pymod: https://github.com/jboy/nim-pymod. Project is dead but it probably still compiles
09:49:19FromGitter<mratsim> it references the Nimborg project for calling python from Nim
09:53:59*leorize quit (Ping timeout: 260 seconds)
09:55:52FromGitter<narimiran> @mratsim very nice, thanks!
09:57:30*dddddd joined #nim
10:10:54*kaliy quit (Changing host)
10:10:54*kaliy joined #nim
10:13:50FromGitter<dom96> FWIW I like that I can use the times module in the C and JS backend with no code changes.
10:14:07FromGitter<dom96> We shouldn't be pursuing the worse alternative
10:14:31FromGitter<dom96> Especially when WASM is right around the corner.
10:14:38FromGitter<alehander42> afaik it would be similar with my node support for other modules, just the code wouldn't be in `when defined(nodejs)` but in different equivalent modules
10:14:57FromGitter<alehander42> you'll still use the same `import os` etc in your code
10:17:31Araqyeah, that's the idea.
10:22:12FromGitter<dom96> Alright. But then I can't help but cringe at using Nim with node, whyyyy?
10:22:22FromGitter<alehander42> electron
10:22:55FromGitter<alehander42> please, no "why electron" .. :D
10:23:34Yardanicowell, it's easier to develop with electron, but it has a *slightly* heavier RAM usage ;)
10:26:04FromGitter<alehander42> I can't wait for the light alternative with the same support for browser + most dekstop platforms
10:26:27FromGitter<dom96> What does electron provide that libcef + some browser-side JS doesn't?
10:30:23FromGitter<alehander42> honestly, I haven't heard of libcef before, I just read a bit about it
10:30:37YardanicoI think electron would be fine if you'll be able to run multiple apps using 1 electron (browser) instance
10:30:43FromGitter<alehander42> but I can ask the same, what benefit does libcef provide ?
10:30:55Yardanicocompare 10 tabs in a browser and 10 different electron apps :(
10:31:59FromGitter<alehander42> e.g. why nobody uses libcef compared to electron
10:32:30FromGitter<dom96> Because people are scared of anything that isn't JS
10:32:45FromGitter<dom96> I'm pretty sure electron is built on libcef.
10:33:23FromGitter<dom96> I was hoping you could tell me what electron brings to the table :(
10:33:26AraqI tried libcef once and couldn't figure it out
10:33:27FromGitter<alehander42> @Yardanico I agree, but I guess most electron apps can depend on different electron versions
10:33:56Araqor maybe something else, but these APIs to browser functionality are a waste of time
10:34:00FromGitter<alehander42> well I guess that's the whole point, why should I lose time in getting familiar with libcef if I can just use electron
10:34:20FromGitter<alehander42> and still it's a browser in a dekstop app, so it's not as I'll be winning a lot in efficiency
10:34:55FromGitter<dom96> Presumably because you won't have to implement half of Nim's stdlib for node.
10:35:29FromGitter<alehander42> meh, more like 20-30 functions which I assembled incrementally (which are usually 1-2 line translations)
10:35:58Araqyeah, the problem is
10:36:13YardanicoIf only Nim had a GUI framework which doesn't depend on wx or qt :) There's NiGui but it's not in active development and doesn't have a lot of features :(
10:36:15FromGitter<dom96> You'd probably get some efficiency gains through.
10:36:18Araqever since we got .importccp for JS wrapping JS is superb :P
10:36:20FromGitter<dom96> *through it
10:36:47AraqYardanico, there is also my ui.nim
10:37:05Yardanicohttps://github.com/nim-lang/ui ?
10:37:09Araqyeah
10:37:18FromGitter<alehander42> I agree, it's quite easy to interact with js stuff these days with nim :D
10:37:20FromGitter<dom96> AFAIK Spotify and steam both use libcef.
10:37:36Yardanicoyeah, Steam uses libcef
10:38:03FromGitter<dom96> You should definitely look into it if you haven't. I'm really curious whether electron is still a better route to take.
10:38:16*kobi7 joined #nim
10:38:26kobi7Hello
10:38:35YardanicoFYI: https://github.com/jangko/nimCEF
10:39:14Yardanicokobi7, hi!
10:39:47kobi7let's say i have two libraries, version 1 and version 2, and I want to reuse some functions from ver 1. Is there a way to import and "re-export", instead of copy pasting?
10:39:53FromGitter<alehander42> also, most of my performance issues currently relate to harder (for me) to optimize problem domain features which can be order of magnitude heavier than electron, so it's just not such a priority
10:39:55kobi7Hi Yardanico, how are you doing?
10:41:03Yardanicokobi7, yes, you can "import oldlib" and "export oldlib", or, if you want to export specific procs (but AFAIK it doesn't work good with generics): "export oldlib.myproc"
10:41:49Yardanicokobi7, https://nim-lang.org/docs/manual.html#modules-export-statement
10:42:00Yardanicooh sorry, wrong link
10:42:19FromGitter<alehander42> if I can dream I'd love to even have desktop optimized UI-s falling back to os-specific toolkits for example, but that just requires a lot more manpower
10:42:28FromGitter<alehander42> but thanks, I'll take a look at libcef when I can
10:42:28Yardanicoah, it's a right link, nvm
10:49:21kobi7Ah, cool.
10:50:14dom96alehander42: I think in the long run we should be aiming to create our own electron
10:50:36dom96We've got a libcef wrapper (which actually looks like it's pretty well maintained :D)
10:51:03dom96Electron seems to be little more than a node.js wrapper over libcef
10:51:22dom96With support for native menus and notifications, crash reporting and windows installers.
10:54:42dom96My prediction: If we don't do this, then Rust will and Rust will use its WASM ability to run the in-browser code very efficiently.
10:54:56dom96It's a possible killer app
10:55:08Araqmy prediction: what Rust does is independent from our actions.
10:55:24Yardanicobut it depends on our community size :)
10:55:27*kobi7 quit (Quit: Leaving)
10:55:36dom96Okay, let me rephrase my predicition: Rust will do this
10:55:40dom96*prediction
10:55:54Araqso what, it's an obvious thing to do given their resources
10:56:36dom96It won't be Rust core developers doing it
10:57:11dom96It will be somebody who loves Rust, which is why I think we should be encouraging developers who are already using electron (!) to do the same for Nim
10:57:18AraqI'll simply ask PMunch when he is around
10:57:39dom96You'll ask him what?
10:58:09Araqwhat he thinks works best
10:58:30Araqhe wrote a DSL for describing UIs that sits on top of a couple of different UI libraries
10:58:45dom96He hasn't used libcef and electron has he?
10:58:59AraqI don't know :-)
10:59:03dom96This isn't about what UI is better
10:59:12dom96libcef/Electron already won
11:00:32FromGitter<alehander42> @dom96 that certainly sounds as a very cool idea
11:01:05dom96Glad you think so :)
11:01:23dom96The electron API doesn't look to be that large: https://electronjs.org/docs
11:01:35dom96And I bet you only use a small subset
11:01:45dom96Translating that to Nim should be trivial ;)
11:02:01Araqok, sorry, I misunderstand your points
11:02:13FromGitter<alehander42> hahaha, well that's a whole another thing
11:02:18*vlad1777d joined #nim
11:02:39FromGitter<alehander42> I'd love to play with those ideas in my free time, but don't count on me :D
11:02:50Araqso your point is, "the people who are sold on electron should improve it for Nim's purposes"
11:03:27dom96sure. I don't want to pick on alehander42 too much though :)
11:03:55FromGitter<alehander42> I already have a bunch of nim-ecosystem stuff in my backlog :D
11:04:05dom96If I had a project that worked best on top of electron I would certainly be trying to do this though.
11:05:39dom96But for now I guess this is another idea to go into my todo list :)
11:07:19FromGitter<alehander42> it's now in my side project todo list to experiment with that too
11:07:33FromGitter<alehander42> just my side project list is very unpredictable :D
11:08:59FromGitter<zacharycarter> wellll
11:09:00dom96Do you have any builds of your electron project that you can share yet?
11:09:04FromGitter<zacharycarter> someone is already working on a wasm target
11:09:06FromGitter<zacharycarter> for Nim
11:09:06FromGitter<alehander42> but I'll take a look at libcef tomorrow, intiguing
11:09:09dom96I'm curious to see how complex the UI is
11:10:19FromGitter<zacharycarter> https://github.com/stisa/nwasm
11:10:21FromGitter<alehander42> @dom96 not anything for share yet, sorry
11:11:06dom96I've been wanting to create a better IRC client since I started programming
11:11:07FromGitter<alehander42> the UI itself is not very complex, but it's not something I'd want to rewrite completely soon(it has an almost useful panel docking system etc which was PITA to get right)
11:11:15dom96Maybe it's time I give libcef a crack
11:12:51dom96zacharycarter: oooooh
11:13:15dom96now that is awesome
11:13:19dom96I love our community :D
11:13:25FromGitter<alehander42> yeah, @stisa works on nwasm, I found it last week and I was very happy about it :D
11:14:31Yardaniconice - https://sourceforge.net/p/codeblocks/tickets/657/
11:14:58FromGitter<dom96> @stisa great job so far :D
11:16:02dom96Yardanico: How are you finding these? :)
11:16:11Yardanicodom96, https://github.com/nim-lang/Nim/wiki/Editor-Support/_compare/2c4a857%5E...2c4a857
11:16:28dom96ahhh
11:16:46dom96Another idea I had was to write a good syntax highlighting test file
11:17:07dom96so that we can ask every syntax highlighter to highlight this file correctly
11:17:19dom96Too many ideas too little time D:
11:17:34Yardanicodom96, great idea, nim syntax is not that complicated so file wouldn't probably be very big
11:18:10FromGitter<zacharycarter> yay! talking to the CEO of that gamedev company today! :D
11:18:16FromGitter<zacharycarter> over the phone anyway
11:18:36FromGitter<zacharycarter> err maybe not today - but at some point in the near future - I guess I passed my initial phone screening
11:19:27*xkapastel quit (Quit: Connection closed for inactivity)
11:20:54*leorize joined #nim
11:21:28FromGitter<alehander42> `cmp` works on tuples, nice
11:22:09FromGitter<zacharycarter> @alehander42 you work at status too?
11:22:41FromGitter<zacharycarter> with @mratsim ?
11:36:22*vlad1777d quit (Ping timeout: 264 seconds)
12:15:02yglukhovAraq, dom96: can you please explain this code to me? https://github.com/nim-lang/Nim/blob/devel/lib/pure/asyncmacro.nim#L326-L329
12:15:43yglukhovWhat case does it cover?
12:18:13dom96hrm, that's a weird one
12:19:30yglukhovI'm playing with auto-futurisation of return type. Dunno if I should consider this case...
12:20:24dom96https://github.com/nim-lang/Nim/commit/7c012cb79748184b66a3cf04fefbd5f89ecbdcd0
12:20:27dom96It was introduce here
12:20:44dom96The issue doesn't explain it
12:21:09dom96nnkCallKinds suggests it's `[]`(Future, string)
12:21:24dom96Is that really a way to write Future[string]?
12:22:11dom96also, auto-futurisation of return type?
12:23:02FromGitter<alehander42> I did auto-futurize my first js async implementation returns, but I admit it's kinda too magical
12:23:11yglukhovyes, so that you don't spell out Future[T] on async proc definition. Just T.
12:23:59yglukhovalehander42: async itself is a lot more magical than that =)
12:24:20FromGitter<alehander42> yeah, but still it's counterintuitive: your return type is actually lying to you
12:24:30FromGitter<alehander42> I know what you mean, I also wanted this feature :D
12:24:50dom96yeah, if your intention is to make a PR for this I'm afraid I won't accept
12:24:59FromGitter<alehander42> also, there is this theoretical "what if you have `Future[Future[T]]` thing ( I admit not very practical)
12:27:37yglukhovyeah, but {.async.} pragma already hints about the return value. so its just redundant typing, no?
12:29:33Yardanicoyglukhov, I already asked dom96 about this, but he disagreed :(
12:29:39Yardanico(about implicit Future return type)
12:29:47yglukhovalehander42. that one is easy. return type is auto futurezed only if it is not Future[T] already
12:32:17dom96My logic is that the return type should tell the truth, I don't want to guess what the async macro is doing
12:33:26dom96I'm also pretty sure that all other languages do it this way.
12:34:35FromDiscord<--HA--> Hello. What would be a good way to compile different code depending on target os? Can I use the when statement to do a different import and define a different proc for windows or linux?
12:34:52Yardanicoyes, you can
12:35:06Yardanicohttps://github.com/nim-lang/Nim/wiki/Consts-defined-by-the-compiler
12:36:36FromDiscord<--HA--> the --os:windows switch that one can pass to the compiler is that what I can check with when defined(Windows)?
12:36:54Yardanicoyes
12:37:07FromGitter<ChristianWitts> that wiki page could do with an update, platform.nim instead of plataform.nim, and linking to extccomp.nim from devel and not an almost 3 y.o. commit
12:37:16Yardanicowell, you can edit it :)
12:37:30Yardaniconim wiki on github can be edited by any github user
12:37:37FromGitter<ChristianWitts> Oh, surprisingly open to the world
12:37:47FromDiscord<--HA--> awesome, thanks
12:37:49Yardanico(that's the default on github btw)
12:38:01yglukhovdom96, fair enough, but don't you think that using an async proc requires some knowledge already? like what's a future, what to do with it, etc? besides, void type is auto-futurized already, so it's just inconsistent.
12:38:30Yardanicooh, I'm sorry, it's not a github default
12:39:02dom96yglukhov: Yes, you need to know about futures, which is why I prefer that they are in "your face" so to speak
12:39:10FromGitter<ChristianWitts> thankfully it’s not a github default, otherwise I’m sure spammer would abuse it.
12:39:20FromGitter<ChristianWitts> I updated the wiki page :)
12:39:24dom96It's not inconsistent. In Nim, the void type is implicit, it's the same for the async macro.
12:39:40YardanicoChristianWitts: cool, thanks!
12:40:02yglukhovdom96: you can't call void async proc without discarding/awaiting it. hence inconsistency.
12:40:37yglukhovyou're looking at the {.async.} proc thinking that it returns nothing, but that's a lie =).
12:41:33Araqbtw .async should forbid the .discardable annoation
12:41:34FromGitter<alehander42> maybe we should just make them `{.discardable.}`, good point! :D
12:42:18FromGitter<alehander42> but indeed, it would be easy to call async function without awaiting it
12:42:42euantorI really wouldn't want the `{.async.}` macro to convert return type to `Future[T]` - I like having to specify that it returns a future
12:43:02euantorI don't mind about `async void` though
12:44:11FromGitter<mratsim> @ChristianWitts see also my last post on the forum: https://forum.nim-lang.org/t/3723
12:44:15yglukhoveuantor: haha, but that just sounds like you're just used to it =).
12:44:22dom96Araq: true
12:44:51yglukhovok, so how come Future[void] is implicit, but Future[T] is not?
12:44:55euantoryglukhov: Yes, and I'm used to it from C# too (having to write `Task<T>`)
12:45:42dom96Araq: Either that, or we need a way to automatically set a callback on non-awaited futures.
12:46:19*noonien joined #nim
12:47:17yglukhovI honestly don't see the point in spelling out smth explicitly when it cannot be otherwise. I mean what's the point (for me) to write Future[T] {.async.}, when Future[T] is the only possible option? That's just not dry =)
12:48:07dom96You have to repeat the word 'proc' a lot too :P
12:48:33AraqI don't mind either way, but I too was confused at first :P
12:49:18Araqproblem is when you transform ': string' to ': Future[string]' then explicit 'Future[string]' would become 'Future[Future[string]]'
12:49:19*smt_ joined #nim
12:49:32Araqand that's really bad.
12:49:46Araqso I think dom96 made the right choice here.
12:50:10dom96I'll be honest, I'm pretty sure I just copied C# here :)
12:50:29dom96For the implicit 'void' I just followed Nim's lead, I think that makes sense.
12:50:49FromGitter<alehander42> if we were perl
12:50:58FromGitter<alehander42> we would just define ~T == Future[T]
12:51:09FromGitter<alehander42> and add one more amazing symbol
12:51:22yglukhovAraq: that one is easy. return type is auto futurezed only if it is not Future[T] already
12:51:41Araqyglukhov, but then it's inconsistent :P
12:51:56FromGitter<alehander42> but that's very confusing, so T == Future[T], Future[T] == Future[T], Future[T] != Future[Future[T]]
12:52:19Araqnot that I mind inconsistencies too much...
12:53:02Araqalehander42: yeah, *shrug*, I wouldn't mind it.
12:53:09Araqbut currently it's simpler.
12:53:22*smt` quit (Ping timeout: 265 seconds)
12:53:34FromGitter<alehander42> I was kidding, but I really think adding some kind of shortcut for your project ( ~T %T or F[T]) would be simpler and more consistent
12:53:55AraqI do think though that we should have an .autoasync
12:54:20Araqthat annotates calls starting with write/read/whatever with 'await' automatically
12:54:38Araqneeds some naming scheme for the dangerous "blocking" calls
12:54:53Araqbut then it would feel like a high-level DSL to me.
12:55:23dom96Not every call to an async proc requires 'await'
12:55:37dom96The programmer should choose consciously, so this isn't worthwhile IMO
12:56:29Araqyeah you're probably right. on the other hand, I cannot even issue HTTPs requests concurrently easily.
12:57:04Araqso the harder stuff is hard already and can be done with the existing .async
12:57:33Araqbut most of the time I 'await' a proc that produces a future.
12:58:18yglukhovI'm thinking of async procs not in terms of return type. Obviously, calling async proc from sync proc will give you a future, but once you're in async world, return value is not a future, and you can't call it synchronously. That's at least how i keep it in mind. Because of that I often forget to enclose return type in Future[], so it's just annoying. Also its a bit inconvenient to transform sync/async/sync procs in the code.
12:58:51dom96Araq: Actually there is a heuristic that could be used to determine 'await' vs. 'asyncCheck'
12:59:09AraqI do mind the 'awaits' more than the Future[T] return types
12:59:27dom96the code semantics could turn out surprising though
12:59:35yglukhovAraq: do you mean you want to get rid of those?
12:59:51*athenot joined #nim
12:59:53Araqit introduces a great amount of friction :P
13:00:11Araqthe whole world is divided into these blocking vs non-blocking calls
13:00:29Araqwhen it's not relevant to the program logic.
13:00:37dom96maybe it's time to scrap this whole thing and adopt Go's approach? :P
13:00:51yglukhovhmm... yeah, it sounds like go...
13:01:19Araqwell I prefer threading.
13:01:28FromGitter<alehander42> uh I think autoinferring `await` is impossible
13:01:50Araqit's not a secret that I think threading plus locks is the best model :P
13:02:38yglukhovdom96: have I at least made you hesitate about auto futurization? ;)
13:02:45FromGitter<alehander42> btw if you use an overloaded funcction that returns Future
13:02:52FromGitter<alehander42> and one overload is truely async
13:02:57FromGitter<alehander42> and the other one returns immediately
13:03:09dom96yglukhov: sure, you certainly made me think about it
13:03:16Araqyou can rule out deadlocks via the .locks annotation and data races with .guard annotations.
13:03:18FromGitter<alehander42> would the second one return immediately even if I `await` it
13:03:54dom96We'll (hopefully) have 'await' support for FlowVar and channels soon
13:04:02FromGitter<alehander42> this way I can `await <x>` with sync and async impl-s in the same time
13:04:09dom96then we'll need a way to transfer FDs between threads
13:04:26dom96and things should be good
13:04:42Araq.async is more efficient than threading
13:04:46yglukhovalehander42: think about it like "implicit discard of future" inserts an await, and makes this proc return future =)
13:04:55Araqbut that doesn't mean I have to like it. I don't.
13:05:06dom96alehander42: I think it is possible
13:05:28dom96Not sure if it's possible with macros
13:05:37dom96but with the amount of knowledge the compiler has, certainly
13:05:46dom96You can just look for how each returned future is used
13:05:54dom96If it's not used then you don't await it
13:06:09dom96(by "used" I mean `read`)
13:06:42dom96Araq: Hrm, is it more efficient?
13:06:50FromGitter<alehander42> what I mean is, can the compiler detect that an async function actually doesn't call anything `async` inside, and directly make it `sync` on the callsite
13:07:02Araqsomething is seriously wrong. I run this code on millions of lines of code called the OS and yet I should be reminded about whether some calls can "block" my program. I don't care if they can. memory reads can block my program, it's called a cache miss, it's expensive but I don't have to write 'await myarray[i]' everywhere because of that.
13:07:24dom96As much as I love async await, I often wonder whether Goroutines are a better approach
13:08:00Araqbetter is not a good word. it's easier to use in a couple of aspects.
13:08:10Araqit's worse in other aspects.
13:08:23dom96Araq: That's a good point. I think Microsoft did an experiment to write an async OS
13:08:36dom96And I suppose it made IO calls which blocked transparent
13:08:42dom96in the same way that memory access is transparent
13:08:58FromGitter<alehander42> well it's all about treshholds
13:09:20FromGitter<alehander42> the things that you think can be slow enough to be "blocking" can be awaited
13:09:52dom96yeah, there isn't enough time in a cache miss to warrant doing other work
13:10:08Araqthere is, it's called hyperthreading.
13:11:55FromGitter<dandevelo> Can one have two procs with same name but different return types in Nim?
13:12:21YardanicoAFAIK you can't for now
13:12:26Yardanicothere's no return type overloading (yet)
13:13:09Araqand if we're after a simple concurrency model, I wouldn't pick Go's channels but locks. But I'm probably nuts on this one.
13:14:01dom96Yardanico: I don't think it's "yet" :)
13:14:20dom96Araq: I guess you're after a "simple and safe" model
13:14:36dom96although, hrm, Go's channels are safe too I suppose
13:14:40dom96Why locks then?
13:15:29Araqbecause they are simpler, ymmv.
13:16:01Araqthey got a bad reputation because of deadlocks and data races but both problems can be solved.
13:16:18dom96yeah... I think solving those problems makes them complicated :)
13:16:39Araqthey don't.
13:16:39FromGitter<narimiran> @dandevelo i have just tried it and i get `ambiguous call`
13:16:54AraqI take deadlocks over live-locks.
13:17:18Araqor weird transactional semantics with nested rollback behaviours :P
13:17:26FromGitter<dandevelo> Thanks @Yardanico & @narimiran . Indeed, it looks like it is not supported
13:17:30dom96I would personally prefer channels
13:17:59dom96but if Nim gets GC'd shared memory protected by locks then I'll happily use it
13:18:44Araqthat's the thing. you cannot even build a realistic shared GC on top of message passing.
13:19:00Araqok, the Pony people claimed success.
13:19:40dom96yep
13:21:15Araqwell I like locks, deal with it. I also prefer polling over event notifications
13:21:37dom96That's simply inefficient though
13:22:05AraqI'm talking about convenient concurrency models.
13:22:49Araqefficiency is not my point.
13:23:00dom96isn't concurrency what async is?
13:23:06Araqyes.
13:23:11dom96you mean parallel models
13:23:41Araqwell I'm fuzzy enough to mean both aspects.
13:24:25dom96There does seem to be demand for semaphores and things for concurrency too
13:25:34dom96well, I was arguing with someone about async await in #crystal-lang yesterday
13:26:16Araqso this is how you spend your time :P
13:26:20dom96and they really preferred Crystal's approach
13:26:31dom96only sometimes :P
13:26:33Araqwhat a wonder
13:26:51dom96It's interesting to hear other people's perspectives
13:31:19livcddom96: what time ?
13:33:07dom96Pretty much exactly 24 hours ago
13:33:32*smt_ quit (Read error: Connection reset by peer)
13:34:17*smt joined #nim
13:55:34FromGitter<nathandaly> Really liking nim
13:56:17*leorize quit (Quit: WeeChat 2.1)
13:58:17*athenot quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
14:00:29dom96nathandaly: :D
14:01:33FromGitter<dandevelo> Given this code: https://www.paste.org/92350 on line 7: should that be "object of T1" or "object of T1Impl" ?
14:02:07Yardanicodandevelo: do you really need Impl types?
14:02:25YardanicoYou can directly create T1 as an `ref object of RootObj`
14:02:28dom96yeah
14:05:13FromGitter<dandevelo> @Yardanico I got this habit when manually allocating memory and working with ptr instead of ref
14:09:10dom96You're better off either using 'ref' or not using it
14:09:14dom96so don't define both
14:11:21*miran joined #nim
14:16:17*leorize joined #nim
14:25:06FromGitter<krux02> I just implemented in macros module `symKind` on the `NimNode` instead of `NimSym`, but I gave it the same magic as that function and it kind of already worked.
14:25:15FromGitter<krux02> no change in the nimVM required
14:25:48FromGitter<krux02> it kind of works, because when I call symSym on anything that is not a nimSym, then it fails
14:26:05*athenot_ joined #nim
14:28:23*athenot_ quit (Read error: Connection reset by peer)
14:29:12*endragor quit (Remote host closed the connection)
14:30:54*athenot_ joined #nim
14:32:48*endragor joined #nim
14:32:56*SenasOzys quit (Ping timeout: 265 seconds)
14:35:48Araqcool
14:35:57FromGitter<alehander42> @dom96 I tried to tl;dr my final thoughts about libcef-based library in https://github.com/nim-lang/Nim/issues/7505#issuecomment-378949200
14:37:16FromGitter<krux02> Araq: hmm I kind of need a kind on what error should be reported, when I call symKind or getImpl on a nimNode that is not a symbol
14:37:34*endragor quit (Ping timeout: 268 seconds)
14:37:34FromGitter<krux02> second kind shold have been hint
14:38:00FromGitter<alehander42> it just doesn't seem worth it for me if it doesn't include some more radical UI-stuff (maybe something like xray, where one can move a lot of the UI logic itself in native Nim which just renders/accepts input using the browser?)
14:38:25FromGitter<krux02> currently it is this: Error: field 'symbol' cannot be found
14:38:35*SenasOzys joined #nim
14:38:50FromGitter<krux02> but field symbol doesn't really exist anymore, so I would prefer an error that people can actually understand
14:44:48*endragor joined #nim
14:49:22*endragor quit (Ping timeout: 265 seconds)
14:51:57*athenot_ quit (Ping timeout: 260 seconds)
14:57:57FromGitter<mratsim> “Error this is not a NimSym, couldn’t find a ‘symbol’ field”?
15:03:08dom96"This is not a NimSym" seems sufficient
15:03:16dom96or "Expected NimSym, got ..."
15:07:42FromGitter<gogolxdong> Are you arguing what the async mechainsm is going to be in the next version?
15:09:18*athenot joined #nim
15:10:13*leorize quit (Quit: WeeChat 2.1)
15:10:20FromGitter<krux02> dom96: I am removing/deprecating the NimSym type, because it is much more useful to use the `NimNode` directly
15:10:55FromGitter<krux02> so saynig `this is not a NimSym is kind of confusing if at some point that type really is removed
15:11:26dom96Right, so presumably only certain Nim node kinds have a 'symbol', right?
15:11:45dom96"This Nim node kind does not have an associated symbol"
15:11:46FromGitter<krux02> yes
15:11:48FromGitter<krux02> only one
15:12:04dom96okay then mention it
15:12:06FromGitter<krux02> again you are talking about symbol
15:12:17FromGitter<krux02> talking about symbol is confusing
15:13:39dom96What is the node kind that has it?
15:15:44*craigger quit (Quit: bye)
15:17:55*craigger joined #nim
15:18:19FromGitter<sivakon> Is there a good example on how to use c2nim? Any help would be appreciated.
15:18:48YardanicoI actually have a gist which may help
15:19:14Yardanicohttps://gist.github.com/zacharycarter/846869eb3423e20af04dea226b65c18f
15:19:33Yardanicoit's made by @zacharycarter
15:19:42FromGitter<cabhishek> @sivakon also, take a look at https://github.com/genotrance/nimgen
15:20:04Yardanicoyeah, nimgen is very good
15:20:20FromGitter<cabhishek> @Yardanico I didn't know about the gist. Thanks :)
15:20:48FromGitter<sivakon> Great. Thanks. I am trying to wrap Open AI Gym for Nim.
15:23:04dom96oooh, that's a nice guide
15:23:42dom96The chapter on the FFI of my book is freely available too: https://manning-content.s3.amazonaws.com/download/5/08b3cf8-cea3-42c1-97b5-b5047c472b73/SampleCh08.pdf
15:23:44Yardanicodom96, sadly it's not completed :)
15:25:00dom96and there is this too https://nim-lang.org/docs/c2nim.html
15:25:36FromGitter<sivakon> Great. Can I use it to wrap C++ headers too?
15:26:19*Trustable joined #nim
15:26:57dom96yeah
15:26:58Yardanicoyes
15:27:29Yardanicobut c2nim can't translate any C/C++ headers
15:27:35Yardanicosometimes you'll need to make changes manually
15:28:16FromGitter<sivakon> @dom96, @Yardanico Sure. Thanks a ton.
15:29:07FromGitter<alehander42> what is the diff between
15:29:15FromGitter<alehander42> Option and GlobalOption ?
15:29:33*smt quit (Read error: Connection reset by peer)
15:29:40FromGitter<alehander42> it seems we already have 32 GlobalOption-s , so I don't have a choice I guess
15:29:54Yardanicowait, what is a GlobalOption?
15:30:00FromGitter<alehander42> the nim compiler options
15:30:10Yardanicohmm, I don't really know :P
15:44:54*nsf quit (Quit: WeeChat 2.0.1)
15:46:04*aguspiza joined #nim
16:01:25shashlick@sivakon: openAI gym looks like it is written in Python - where are the C/C++ headers?
16:04:17FromGitter<krux02> dom96: sorry for the late reply, "What is the node kind that has it?" the node kind is nnkSym.
16:04:51dom96So the error message should be simple: "Expected nnkSym, got ..."
16:06:02FromGitter<krux02> yea, I will do that.
16:06:26FromGitter<krux02> doesn't look as nice as I hoped it would. but yea it will do
16:09:03*Jesin joined #nim
16:10:19shashlickwho manages the FromGitter bot? will be cool if it can show gitter gists like how it does when you connect to the gitter irc bridge (as plain text)
16:10:33Yardanicoshashlick, oprypin does
16:10:44*yhb joined #nim
16:14:14FromGitter<alehander42> ah when you wonder why it's not working and you haven't even linked the resource
16:14:18FromGitter<alehander42> i am stupid
16:16:43*yhb quit (Quit: Page closed)
16:16:54FromGitter<krux02> well i decided for "node is not a symbol", I hope that is a precise error message
16:17:13FromGitter<krux02> that also won't confuse anybody
16:18:03dom96shashlick: how could it do that? it would be far too long on IRC
16:24:52*xkapastel joined #nim
16:24:53shashlickdom96: it just shows up as multiple messages - let me show you a screenshot of how it looks
16:24:59*Jesin quit (Quit: Leaving)
16:25:55Yardanicoshashlick, it will still be very annoying
16:27:13miranagreed - too long and annoying for irc
16:32:31*sendell quit (Remote host closed the connection)
16:32:36*Jesin joined #nim
16:37:53FromGitter<alehander42> I have nim js source maps working locally
16:38:50FromGitter<alehander42> An initial PR (I still need to add tests) https://github.com/nim-lang/Nim/pull/7508
16:46:17*athenot quit (Ping timeout: 260 seconds)
16:46:25dom96seems you've got zah's changes mixed up in there
16:46:51*athenot joined #nim
16:47:21shashlickhttps://imgur.com/a/C3ykq
16:47:33shashlickYardanico: I picked your last post :)
16:48:22Yardanicoshashlick, this is on Gitter
16:48:54shashlickya, so it shows up that way when you connect to gitter via their irc bridge - irc.gitter.com
16:49:23shashlickconsidering gitter shows those gists inline, it would be nice to see it the same way on irc as well, since so many people use gitter
16:49:36shashlickit would get logged also inline by the nim bot
16:49:38dom96Gitter's IRC must not have any message rate limiting then
16:49:52dom96FreeNode will kill a client if it sends messages too fast
16:49:59dom96so this isn't practical
16:50:31miranshashlick: what's wrong with the current situation where you get a link, you click on it, and see the code in gitter?
16:52:34shashlickthen you might as well use gitter :D
16:52:58FromGitter<narimiran> i might do that indeed :D
16:57:53dom96hrm, this gave me the thought to try a multi-im client. Found this: https://meetfranz.com/
16:57:57dom96You guys know of any others?
16:58:26mirani have tried franz on my linux machine, but wasn't very satisfied
16:58:33dom96How come?
16:58:50dom96I'd try it but it doesn't seem to support IRC
16:59:41miranthere was a post about one very lightweight (~100 KB) multi-im. it said coming soon for linux so i hadn't tried it, and i forgot its name :)
17:00:18Yardanicomiran, :(
17:00:56shashlickdom96: looks like 1 sec per line is a safe throttle rate - there's no explicit rate I could find for freenode
17:01:19miranit was some guy working on it, closed source at the moment, and he said he will open source it later
17:01:24shashlickbut that could break up a message if someone else posts in the middle
17:02:03dom96shashlick: yes, far too slow
17:02:15shashlickam checking on #freenode if they can make any exceptions for legitimate bots
17:02:22dom96There is a reason you'll get banned from any IRC channel if you refuse to pastebin your code and instead paste it into IRC directly
17:05:43*shodan45_ quit (Remote host closed the connection)
17:06:04*shodan45 joined #nim
17:07:08shashlicksounds fair but guess more will move to gitter - smart of them to inline their gists and not post them as separate links. the links to their gists in irc take you straight to the chat room
17:08:14*onionhammer1 joined #nim
17:08:24FromDiscord<treeform> I managed to get basic source maps working in JavaScript:
17:08:25FromDiscord<treeform>
17:08:25FromDiscord<treeform> https://cdn.discordapp.com/attachments/371759389889003532/431500368569171978/unknown.png
17:09:05*byte512_ quit (Ping timeout: 240 seconds)
17:09:07*shmup left #nim (#nim)
17:09:43dom96treeform: is your approach separate from alehander42's?
17:09:53FromDiscord<treeform> I don't know what alehander42's is.
17:10:11shashlickat least I can do something about the FromGitter / FromIRC annoyance - weechat can rewrite them to look seamless, becoming quite fun to use weechat with all it's capabilities
17:10:12*onionhammer quit (Ping timeout: 255 seconds)
17:10:14*shodan45 quit (Remote host closed the connection)
17:10:32FromDiscord<treeform> dom96, what was their approach?
17:10:48dom96treeform: I'm not sure, he just made a PR for it: https://github.com/nim-lang/Nim/pull/7508
17:10:57dom96(which seems to have mixed up some other commits)
17:11:37FromDiscord<treeform> I am just reading the generated JS file and looking for things that look like `F.line =` and `var F={` and generating source maps off that. Not part of nim compiler.
17:11:53dom96ooh
17:12:39shashlickFYI - from #freenode - burst of 4 messages and then 1 per 2s is a safe target in case anyone needs to know
17:12:43*shodan45 joined #nim
17:12:47dom96Will you make it available as a Nimble package or something?
17:13:15FromDiscord<treeform> dom96, `F.line =`s are very buggy, so that is the main thing that needs fixing.
17:16:13FromGitter<alehander42> @treeform @dom96 I just use the hot reloading branch in my project, that's why it's based on it
17:16:18FromGitter<alehander42> you can just look at the last commit
17:16:38FromGitter<alehander42> (I can rebase, I honestly thought the reloading is already merged :P )
17:16:56FromGitter<alehander42> I do something similar, but I use `// line`
17:17:03FromGitter<alehander42> I fixed some of the wrong
17:17:12FromGitter<alehander42> `genLineDir` and added some more
17:17:33*byte512 joined #nim
17:17:36FromGitter<alehander42> and I am sure my approach is correct when `genLineDir` is used correctly
17:18:03FromGitter<alehander42> (it's simpler than `F.line = ..` and it implies just `lineDir`)
17:18:26mirandom96: i'm trying to make a PR and apparently i'm 27 commits ahead of devel!? (i have made one commit)
17:18:45FromGitter<alehander42> @treeform do you generate the source maps using the `source-map` js lib?
17:18:57FromGitter<alehander42> I did that initially , but then I ported the gen part of it to nim
17:19:07FromGitter<alehander42> so now the compiler can do it directly
17:19:35mirani guess it is an error on my side, but i have seen another PR with some old commits from others....
17:19:56dom96miran: it's a fairly common mistake :)
17:20:04FromDiscord<treeform> alehander42, do you --lineDir:on and look at `// line` ?
17:20:10dom96no idea what the cause might be though
17:20:16FromGitter<alehander42> I believe that this approach is almost optimal, maybe we can hook creation of SourceNode-s directly to genLineDir and then make generation of code aware of the last line, but that's way more complicated
17:20:17FromDiscord<treeform> I looked into that but it seemed to be the same info as `F.line =`
17:20:54FromDiscord<treeform> alehander42, I ported the parts of source-map js I need to nim.
17:21:04FromGitter<alehander42> @treeform yes, I enable `lineDir` when I pass `sourceMap` to the compiler
17:21:17FromGitter<alehander42> it is, but I improved genLineDir somewhat
17:21:26FromGitter<alehander42> and the jsgen line dir generation
17:21:33FromDiscord<treeform> alehander42, https://gist.github.com/treeform/c95e4073a6f5942d8192a4d425cb885f
17:21:35FromGitter<alehander42> also, I use now soft newlines when lineDir is on
17:22:05mirandom96: any advice on what should i do?
17:22:23FromGitter<alehander42> so I can generate exactly one js line for one Nim line if I need to (which might be not necessary)
17:22:51FromGitter<alehander42> @treeform me too, my code looks very similarly
17:22:56FromGitter<alehander42> if you take a look at the PR
17:22:58*byte512 quit (Ping timeout: 240 seconds)
17:23:03FromGitter<alehander42> :D
17:23:34dom96miran: where is your PR?
17:23:45dom96or rather I guess branch
17:24:06mirani didn't publish it because of all that old unwanted commits coming with it
17:24:29dom96so link me your branch
17:24:42*byte512 joined #nim
17:24:54dom96also, if you could recount the steps you took that might help diagnose how you arrived at this problem
17:25:05miranhttps://github.com/narimiran/Nim/tree/fix-replace
17:25:54FromDiscord<treeform> alehander42, your patch seems to focus a ton on hot code reloading
17:26:06mirani guess i had a "dirty" local `devel`
17:26:42FromDiscord<treeform> alehander42, my next step was to see if I can make the line generation better... but it looks like you already done some stuff.
17:26:57FromDiscord<treeform> alehander42, also what are your thoughts on name mangling?
17:27:01dom96miran: strange
17:27:54dom96miran: I would just start over from a fresh `devel`
17:28:09dom96before making your changes, make sure it's up to date
17:28:28miranok, i'm rusty with git, how do i do that (start over fresh)
17:29:09dom96git checkout devel
17:29:14dom96git pull
17:29:29dom96git status # double check it all looks good
17:29:37dom96then you should be able to make your changes
17:29:58dom96before committing make a new branch: git checkout -b replace-fixes
17:32:02FromDiscord<treeform> alehander42, i think your encode is much better: https://github.com/nim-lang/Nim/pull/7508/files#diff-ff63391d52657b492565ac93bf5c83d0R91 I ported mine from the js lib and its was very confusing.
17:33:35mirandom96: thanks, it works, PR coming any minute now :)
17:33:36FromGitter<alehander42> treeform
17:34:01FromGitter<alehander42> Well name mangling doesn't seem to matter for source maps
17:34:39FromGitter<alehander42> Or maybe it does
17:34:54FromGitter<alehander42> And that's what I am missing in my name field
17:35:26FromDiscord<treeform> yeah I still don't fully understand how the name in source mapping supposed to work
17:35:39FromDiscord<treeform> I just want to fix this problem:
17:35:41FromDiscord<treeform>
17:35:41FromDiscord<treeform> https://cdn.discordapp.com/attachments/371759389889003532/431507230731403264/unknown.png
17:36:20FromGitter<alehander42> What is the problem
17:36:27dom96the fact that it knows that 'i' is a variable :o
17:36:59FromGitter<alehander42> The stack trace?
17:37:05FromDiscord<treeform> alehander42, `i` is actually `i_27019`
17:37:23FromGitter<alehander42> Aaag
17:37:59FromDiscord<treeform> I wish nim would only mangle names when there is a conflict, 99% of the time there is no conflict, and it should just use clean names...
17:38:06FromDiscord<treeform> I don't know how to do that.
17:38:37FromGitter<alehander42> You're trying to watch the variable
17:38:38FromGitter<alehander42> e
17:38:41FromGitter<alehander42> ?*
17:38:54FromDiscord<treeform> yeah watch or hover over it
17:39:02FromDiscord<treeform> also type `i` in console
17:39:18FromDiscord<treeform> i wish nim would just output `i` not `i_27019`
17:39:53FromDiscord<treeform> well thats kind of different from source maps, but related.
17:41:39FromDiscord<treeform> Also I feel like the fianl version, should be source maps were generated in genLineDir (add Mapping) then compiler should just write both files, rather then parse the source looking for `// line`?
17:41:49FromDiscord<treeform> alehander42, thoughts?
17:42:37FromGitter<alehander42> I think I know how to fix it
17:43:58FromDiscord<treeform> alehander42, you sort the mappings, do they need to be sorted? https://github.com/nim-lang/Nim/pull/7508/files#diff-ff63391d52657b492565ac93bf5c83d0R219
17:44:04FromGitter<alehander42> But I am not completely sure it will always work
17:44:07FromDiscord<treeform> I could not find an answer tot his
17:44:11FromGitter<alehander42> For function names
17:44:31FromDiscord<treeform> Yeah name mangling is a hard problem.
17:47:28FromGitter<alehander42> No wait ofc it will work
17:47:44FromGitter<alehander42> Ok, I can add that later tonight
17:48:44FromGitter<alehander42> Or we can also combine efforts @treeform you were first
17:49:22FromGitter<alehander42> We can try
17:49:54FromGitter<alehander42> To combine our impls if something is missing
17:52:34FromDiscord<treeform> alehander42, yeah I am taking your encode functions and putting it into my code.
17:52:42FromDiscord<treeform> your encode function is great
17:53:07FromDiscord<treeform> I don't get what some of your code does, SourceNode and walk?
18:01:48FromDiscord<treeform> slightly cleaned up source map generator: https://gist.github.com/treeform/3ac009556892b100779c6ed38882429b
18:13:30FromGitter<alehander42> It just collects source nodes recursively
18:13:59FromGitter<alehander42> No, I think I know how to handle me mangling correctly
18:14:11FromDiscord<treeform> How?
18:18:12FromGitter<alehander42> I can collect all the name manglings in jsgen
18:18:23FromGitter<alehander42> And then replace
18:18:37FromGitter<alehander42> Their sub source nodes
18:21:08FromGitter<alehander42> With source node with their mangling names
18:21:28FromGitter<alehander42> I am not totally sure that's correct
18:21:38FromGitter<alehander42> I'll try it when I am in home
18:22:54FromDiscord<treeform> I see. I don't think its a blocker for this PR. You should try to get this PR in as is. Then worry about name mangling later.
18:27:16FromDiscord<treeform> what there is another hot code reloading patch? https://github.com/nim-lang/Nim/pull/7362
18:32:21*nsf joined #nim
18:40:42FromGitter<alehander42> Did you also so hot reloading hahaha
18:40:46FromGitter<alehander42> Oh man
18:40:59FromGitter<alehander42> Why not pushing upstream
18:44:08*Jesin quit (Quit: Leaving)
18:47:27*arnetheduck_ quit (Remote host closed the connection)
19:18:47*Vladar quit (Quit: Leaving)
19:19:33*SenasOzys quit (Ping timeout: 264 seconds)
19:26:35*SenasOzys joined #nim
19:30:58mirannim site is down?
19:32:06Yardanicomiran, not for me
19:32:12Yardanicoworkinf perfectly fine
19:33:24miranYardanico: it's back on for me, and docs look different than before (changed font) :/
19:35:11dom96unless somebody is hacking our servers there shouldn't have been any changes to fonts :)
19:36:43miranit's back to the default. strange.
19:37:01mirani kinda like the "new" font :D
19:39:06*noonien quit (Quit: Connection closed for inactivity)
19:45:16FromGitter<zacharycarter> folks were mentioning libcef earlier
19:45:28FromGitter<zacharycarter> also found - https://github.com/zserge/webview | https://github.com/oskca/webview - today
19:47:49dom96I recall somebody mentioning here that they have a beefy server they could let me borrow, for benchmarking purposes
19:48:01dom96Was shashlick?
19:48:03dom96*Was it
19:48:15dom96zacharycarter: I met the guy that created that library at FOSDEM :)
19:48:34FromGitter<zacharycarter> ah cool!
19:48:53dom96https://github.com/zserge/webview/pull/111#issuecomment-367368223
19:49:22dom96I guess I should ping them
19:58:51*Widdershins quit (Ping timeout: 268 seconds)
20:01:58*Widdershins joined #nim
20:02:33shashlickdom96: yep - I can run stuff on it if required
20:04:55dom96shashlick: PM
20:07:17*yglukhov quit (Remote host closed the connection)
20:07:24*Trustable quit (Remote host closed the connection)
20:07:36*yglukhov joined #nim
20:07:51*yglukhov quit (Remote host closed the connection)
20:08:07*yglukhov joined #nim
20:12:32*smt joined #nim
20:12:57*rokups quit (Quit: Connection closed for inactivity)
20:16:24*smt quit (Client Quit)
20:23:39*yglukhov quit (Remote host closed the connection)
20:24:09*rockcavera quit (Remote host closed the connection)
20:24:15*yglukhov joined #nim
20:28:27*yglukhov quit (Ping timeout: 240 seconds)
20:33:54*smt joined #nim
21:00:44FromDiscord<--HA--> I'm still struggling with the windows api. I want to call SetFileTime. To get a HANDLE of a file for that it looks like I need to call CreateFile. That expects a LPCWSTR as the file name. Which is a "ptr uint16" and at that point I'm stuck. How can I get a LPCWSTR from a string (a nim string)?
21:02:14FromDiscord<--HA--> I can't believe all this is necessary to change a file modification time, am I missing something perhaps?
21:05:12*nsf quit (Quit: WeeChat 2.0.1)
21:05:33dom96It seems our stdlib is missing this, perhaps you can use this as a reference? https://github.com/nim-lang/Nim/blob/master/lib/pure/os.nim#L181
21:06:27FromDiscord<--HA--> I'll check that out, thanks
21:06:32dom96yeah, seems you should just use findFirstFile
21:06:51dom96feel free to make a PR for a setLastModificationTime function
21:08:02*jaco60 quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
21:08:57FromDiscord<--HA--> It would be nice to have that in the os module perhaps, like getLastModificationTime a set version of that. At lesat for someone like me who doesn't know anything about win api it would be helpful
21:09:42dom96yep, which is why it'd be great if you could create a PR to add it :)
21:11:27*miran quit (Quit: Konversation terminated!)
21:11:37dom96if you need any help, let me know
21:12:51FromDiscord<--HA--> oh findFirstFile is helpful to see, all of that code in os.nim really. I'll give it a try and let you know how far I get
21:15:28dom96great :)
21:21:09FromGitter<krux02> yay tests for my PR run through
21:21:18FromGitter<krux02> don't merge yet though.
21:22:11FromGitter<krux02> dom96: what do you think about it: https://github.com/nim-lang/Nim/pull/7491
21:23:42FromGitter<data-man> https://www.experts-exchange.com/questions/10054777/Fast-Get-File-Modification-Time.html
21:28:41*rockcavera joined #nim
21:31:53dom96krux02: reviewed it, looks good
21:34:12*tiocavera joined #nim
21:34:12*rockcavera is now known as Guest3210
21:34:12*tiocavera is now known as rockcavera
21:37:18*Guest3210 quit (Ping timeout: 276 seconds)
21:44:16*xkapastel quit (Quit: Connection closed for inactivity)
21:47:24*vlad1777d joined #nim
21:49:34FromGitter<krux02> dom96: what deprecation template?
21:49:46FromGitter<krux02> the replacement procs have the exact same name
21:49:57FromGitter<krux02> should I write that in the comment?
21:50:34dom96yes
21:50:41dom96You need the version in there too
21:50:58dom96**Deprecated since v0.18.2:** use symName instead
22:02:25*xkapastel joined #nim
22:13:14FromGitter<zacharycarter> @gokr small talk got mentioned a few times in our developers slack channel at work today :P
22:14:57*yglukhov joined #nim
22:18:22*cyberlis joined #nim
22:18:54FromDiscord<treeform> alehander42, I did not submit any PRs related to the Javascript stuff, i was working on source maps but you beat me to it. Some one else beat you to the hot code reloading stuff.
22:19:29*yglukhov quit (Ping timeout: 260 seconds)
22:19:32FromGitter<alehander42> no no, my branch was just based on the hot reloading stuff , because I use it in the same project
22:20:08FromGitter<alehander42> it's not mine, it's @zah 's
22:20:21FromDiscord<treeform> oh I see.
22:21:49FromGitter<Varriount> @zacharycarter I almost have all the aws v4 signing code written.
22:22:24FromGitter<Varriount> The only thing left is tying the individual parts together, then testing the output
22:22:33FromGitter<zacharycarter> :D
22:23:00FromGitter<zacharycarter> awesome!
22:23:34FromGitter<zacharycarter> I'm working on some playground improvements / modifications right now
22:24:48FromGitter<Varriount> @zacharycarter Could your playground be adapted to other languages?
22:27:19dom96Varriount: Why would you perform such blasphemy?
22:28:47FromGitter<zacharycarter> @Varriount sure - I stole the concept from Rust anyway
22:29:17FromGitter<Varriount> I need to sandbox python
22:29:29FromGitter<alehander42> @treeform btw do your sourcemaps work well in firefox? I am working mostly with devtools
22:30:19FromGitter<zacharycarter> @Varriount jupyter notebook :P
22:31:06FromGitter<zacharycarter> @Varriount - do you guys use kubernetes at work?
22:31:06FromGitter<alehander42> it seems if I step through `yield` in firefox debugger, it hangs somehow, but it seems to work in chrome
22:31:09dom96Varriount: https://repl.it/
22:33:34FromGitter<Varriount> dom96: I need it for work
22:35:45FromGitter<zacharycarter> https://github.com/NightDiveStudios/shockmac
22:37:42*xet7 quit (Remote host closed the connection)
22:39:52dom96zacharycarter: I posted that in offtopic already ;)
22:42:05FromGitter<zacharycarter> oh whoops
22:42:40FromGitter<zacharycarter> can I get in offtopic on gitter?
22:43:29*vlad1777d quit (Remote host closed the connection)
22:43:30FromGitter<zacharycarter> I just need to get off gitter...
22:43:34FromGitter<zacharycarter> and find a decent IRC client for osx
22:45:01*vlad1777d joined #nim
22:48:38dom96I'm using XChat Azure on OSX
22:49:15dom96I think the Gitter channel is called "twitch" for some reason...
22:59:10*cyberlis quit (Quit: Leaving)
23:14:54*aguspiza quit (Ping timeout: 260 seconds)
23:52:27*vlad1777d quit (Ping timeout: 240 seconds)
23:53:13FromGitter<alehander42> ah when you've been checking the wrong seq for an element the while time
23:54:20FromGitter<alehander42> yes
23:54:57FromGitter<alehander42> https://imgur.com/a/MdleB
23:55:23FromGitter<alehander42> @treeform it seems name watch works for me now
23:57:02FromDiscord<treeform> nice!
23:57:04FromDiscord<treeform> how did you do this?