<< 23-11-2019 >>
00:02:46*jua_ quit (Quit: Leaving)
00:27:05*ng0 quit (Quit: Alexa, when is the end of world?)
00:30:07*abm joined #nim
00:48:41*marquis_ joined #nim
00:59:50*abm quit (Quit: Leaving)
01:00:07*marquis_ quit (Quit: Leaving)
01:07:25*Hideki_ joined #nim
01:09:13*sealmove joined #nim
01:28:57*couven92 quit (Ping timeout: 240 seconds)
02:01:05FromDiscord_<exelotl> hey, would anyone good with opengl be able to help me figure out why my damn hello-world triangle isn't rendering? :(
02:01:11FromDiscord_<exelotl> https://gist.github.com/exelotl/d0d271fbc070bffbd665e9780581bba1
02:17:49*pbb quit (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.)
02:24:55*pbb joined #nim
02:29:01*endragor joined #nim
02:30:33*endragor quit (Remote host closed the connection)
02:31:05*endragor joined #nim
02:34:24*krux02 joined #nim
02:52:29*mwbrown quit (Ping timeout: 246 seconds)
02:53:00*krux02 quit (Remote host closed the connection)
02:57:23*sealmove quit (Quit: WeeChat 2.6)
02:59:12*mwbrown joined #nim
03:13:04*uu91 quit (Read error: Connection reset by peer)
03:13:16*uu91 joined #nim
03:24:20*endragor quit (Remote host closed the connection)
03:25:14*endragor joined #nim
03:26:13disruptek!github googlesearch
03:26:14disbothttps://github.com/xyb/googlesearch.nim -- Nim library for scraping google search results
03:27:37FromGitter<Willyboar> !github fullstack
03:27:37disbothttps://github.com/itsumura-h/nim-basolato -- A fullstack web framework for Nim based on Jester
03:27:38disbothttps://github.com/blakeanedved/fullstacknim -- A repository for testing a fullstack nim web development framework
03:33:31*Hideki_ quit (Remote host closed the connection)
03:33:57*endragor quit (Remote host closed the connection)
03:34:16*Hideki_ joined #nim
03:36:43*endragor_ joined #nim
03:37:12*Hideki_ quit (Remote host closed the connection)
03:37:24*Hideki_ joined #nim
03:58:57*endragor_ quit (Remote host closed the connection)
04:15:28*dchem joined #nim
04:16:09dchemhi everyone, is anyone working on a OAS generator for jester?
04:16:23disruptekoas?
04:16:31dchemopenapi standard
04:16:37dchemlike swagger
04:16:48disruptek!github disruptek/openapi
04:16:49disbothttps://github.com/disruptek/openapi -- OpenAPI Code Generator for Nim
04:17:07dchemthat's the client generator I think
04:17:12disruptekit only does the client at present, but you are welcome to modify it.
04:17:27dchemok, will look into it, thank you
04:20:33*endragor joined #nim
04:20:59*chemist69 quit (Ping timeout: 252 seconds)
04:22:50*chemist69 joined #nim
04:33:59*theelous3 quit (Ping timeout: 246 seconds)
04:43:55*nsf joined #nim
04:48:49disruptekAraq and narimiran: any opinion on backporting #12602 ?
04:48:50disbothttps://github.com/nim-lang/Nim/issues/12602
04:48:50disbot^ export nim.cfg parser for use by other tools
05:08:37*Hideki_ quit (Remote host closed the connection)
05:09:41*Hideki_ joined #nim
05:10:45*Hideki_ quit (Remote host closed the connection)
05:11:01*Hideki_ joined #nim
05:20:43*Hideki_ quit (Remote host closed the connection)
05:21:33*Hideki_ joined #nim
05:26:11*Hideki_ quit (Ping timeout: 276 seconds)
05:34:27Araqdisruptek: was backported
05:34:45disruptekthanks 👍
05:35:10Araqbtw your bot is really awesome now
05:35:13disruptekwait, are you sure?
05:35:20Araqso helpful to expand these links
05:35:32disruptekhappy to help.
05:35:43Araqdisruptek: I'm not sure but Miran asked about it and I said "yes"
05:35:48shashlickAraq: up really late no?
05:35:54disruptekyou guys put two other lil PRs in for nim.cfg but not that one.
05:36:01shashlickor perhaps it's morning already 🙂
05:36:27Araqearly morning here
05:36:41Araqdisruptek: uoh my bad
05:36:56disrupteki forget what i was gonna add to the bot but i know someone will remind me. 😁
05:37:06disrupteksup shashlick
05:37:14Araqit were the other nim.cfg features indeed
05:37:39shashlickdisruptek: good good, finally the weekend
05:37:54disruptekyeah, time to do some work.
05:39:42disruptek1.0.4 seems to work for my stuff except for that lil export issue.
05:41:27FromDiscord_<demotomohiro> @exelotl try replacing your vertex shader with this minimal vertex shader.
05:41:27FromDiscord_<demotomohiro> Or enable debug context.
05:41:27FromDiscord_<demotomohiro> https://github.com/demotomohiro/nim-4k-intro-sample/blob/master/shaders/triangle.vs
05:51:45*endragor quit (Remote host closed the connection)
05:54:04*Hideki_ joined #nim
05:57:27*ftsf joined #nim
06:04:23*minierolls joined #nim
06:04:46minierollshey, does anyone know how to specify latest Git version in nimble file?
06:04:55minierollsI know you can do nimble install [package]@#head
06:05:11disruptek"package#head"
06:05:12minierollsbut not sure how to write that for a requires in a .nimble
06:05:14minierollsoooo
06:05:16minierollsthanks!
06:05:19disrupteknp
06:07:53disruptekas requirements go, it's a pretty bad idea, of course.
06:12:17*Hideki_ quit (Ping timeout: 240 seconds)
06:17:17minierollsyeah, don't want to use it but a dependency that I rely on hasn't released a fix yet to nimble version
06:17:19madpropshow do i return a property (orderedTable) of an object? it seems to get it as an iterator
06:17:29madpropsif i do "return db.items" (the property is called items)
06:18:30disruptekmadprops: use sequtils.toSeq to convert an iterator to a sequence.
06:18:51disruptekminierolls: just specify the commit hash you need instead of `head`.
06:19:28madpropsdisruptek: the thing is .. im trying to return the table itself, which is called items
06:19:32madpropsdb.items
06:19:38madpropsdb=object items=orderedTable
06:20:31madpropsmaybe i chose a bad name for a property
06:20:48minierollsoh ok, didn't know i could do that
06:20:50minierollsthanks
06:21:10disruptekit's not worse, and for a package manager like mine, it will be better.
06:22:20disruptekmadprops: is db something that might be iterable otherwise?
06:22:46disruptekbecause i wouldn't expect it to match items()...
06:22:47madpropsdb is just an `object`
06:23:42disruptekcan i see the error message?
06:26:14disrupteki'm having a hard time reproducing that problem.
06:27:04disruptekone work-around to disambiguate that occurs to me is `return db.SomeDbType.items` but again, it shouldn't be necessary.
06:30:50*solitudesf joined #nim
06:31:57*endragor joined #nim
06:37:23*endragor quit (Ping timeout: 252 seconds)
06:58:36*Hideki_ joined #nim
07:00:08*Hideki_ quit (Remote host closed the connection)
07:00:46*Hideki_ joined #nim
07:04:31*endragor joined #nim
07:05:34*Hideki_ quit (Ping timeout: 265 seconds)
07:09:14*endragor quit (Ping timeout: 240 seconds)
07:12:43*Hideki_ joined #nim
07:18:57*dchem quit (Ping timeout: 240 seconds)
07:26:11*narimiran joined #nim
07:48:53AraqGordonBGood: I think I found the problem with your lazy evaluation stuff
07:50:36*solitudesf quit (Ping timeout: 240 seconds)
08:00:00*gmpreussner quit (Quit: kthxbye)
08:00:18*Hideki_ quit (Remote host closed the connection)
08:01:52*Hideki_ joined #nim
08:05:04*gmpreussner joined #nim
08:06:05*Hideki_ quit (Ping timeout: 250 seconds)
08:07:10*Hideki_ joined #nim
08:13:34*endragor joined #nim
08:18:13*endragor quit (Ping timeout: 252 seconds)
08:50:55*endragor joined #nim
08:55:17*endragor quit (Ping timeout: 240 seconds)
08:58:20ZevvSometimes I'm surprised by the lack of symmetry in generics: is there a technical reason why it is not possible to differentiate procs by return type? (apart from the abiguity it might cause when the compiler can not infer what the return type would need to be?)
08:59:04Zevvfor example, I now have a nice bunch of `put()` procs to serialize data, whatever I feed them, but I still need `getu8()`, `getu16()` etc for deserialization.
09:00:39*npgm quit (Ping timeout: 264 seconds)
09:02:05*npgm joined #nim
09:12:39*madprops quit (Ping timeout: 264 seconds)
09:13:00*db93858 joined #nim
09:24:55*Hideki_ quit (Remote host closed the connection)
09:27:56*Hideki_ joined #nim
09:28:33*tklohna joined #nim
09:32:02*Hideki_ quit (Ping timeout: 240 seconds)
09:33:23*letto quit (Ping timeout: 252 seconds)
09:41:57*Hideki_ joined #nim
09:42:30*dddddd quit (Remote host closed the connection)
09:48:25*endragor joined #nim
09:50:07*sealmove joined #nim
09:52:37*endragor quit (Ping timeout: 240 seconds)
09:57:58*ng0 joined #nim
09:59:23FromDiscord_<Lantos> anyone able to help me out with this async proc?
09:59:23FromDiscord_<Lantos> https://play.nim-lang.org/#ix=22Bn
10:10:58*WilhelmVonWeiner left #nim (#nim)
10:13:02*couven92 joined #nim
10:18:16*ponyrider quit (Quit: WeeChat 2.6)
10:18:45sealmovehow does importing a global var work?
10:24:08*ponyrider joined #nim
10:27:39FromDiscord_<mratsim> @Zevv I suppose instantiation by return type would require some backtracking
10:28:03FromDiscord_<mratsim> let's solve the need of forward declaration first 😉
10:28:23FromDiscord_<mratsim> Is there even a language that does inference by return type?
10:28:58FromDiscord_<mratsim> @sealmove var myCvar {.importc: "my_imported_c_name".} = object
10:29:31FromGitter<alehander92> Lantos
10:29:37FromDiscord_<mratsim> you can change it to cint, csize_t, array, or an object and specify the fields
10:29:54FromGitter<alehander92> hey just several things: change name: "lantos" to name="lantos" (thats how works)
10:30:07FromGitter<alehander92> import asyncdispatch
10:30:13FromDiscord_<mratsim> @Lantos, don't waitFor in async, AFAIK it should be an error
10:30:23FromGitter<alehander92> yeah i never finished this pr sorry
10:30:30FromGitter<alehander92> or did at all i dont remember
10:30:49FromGitter<alehander92> and always follow what type is
10:30:56FromGitter<alehander92> see "hello" & name
10:31:01FromGitter<alehander92> its string : you cant await it
10:31:05sealmovemratsim: I am sure there are languages that infer type from return type
10:31:07FromGitter<alehander92> you can only await Future
10:31:21FromGitter<alehander92> so return directly => async automatically makes it future
10:31:35FromGitter<alehander92> in the same way you probably dont want to echo asyncCall()
10:31:39FromDiscord_<mratsim> @sealmove, I'm not aware of any though
10:31:42FromGitter<alehander92> but echo await async_greet
10:31:45FromGitter<alehander92> there are
10:31:46FromGitter<alehander92> haskell
10:32:05FromGitter<alehander92> hm i just found this https://eli.thegreenplace.net/2018/return-type-polymorphism-in-haskell/
10:33:06FromDiscord_<mratsim> interesting
10:33:26FromDiscord_<Lantos> it is requiring me to waitFor sleepAsync
10:33:26FromDiscord_<Lantos> if I remove waitFor it fails: "sleepAsync must be descarded"
10:33:35FromDiscord_<Lantos> discarded*
10:34:14FromDiscord_<mratsim> asyncCheck
10:34:40FromGitter<alehander92> but noo
10:34:42FromGitter<alehander92> just use await
10:34:50FromGitter<alehander92> thats what you do when you have async calls
10:35:10FromGitter<alehander92> see, its confusing at first but its simple
10:35:22FromDiscord_<mratsim> ah no await, asyncCheck doesn't wait
10:35:26FromGitter<alehander92> if you're in async function: you await(or asyncCheck only if you want to discard)
10:35:39FromGitter<alehander92> if you're into sync function: you waitFor or set callbacks i think?
10:36:02FromDiscord_<mratsim> you waitFor if you want to block but discard
10:36:05FromGitter<alehander92> but yeah callbacks actually are the other option for async function sorry, in sync function you mostly waitFor imo
10:36:10FromDiscord_<mratsim> you await if you want the result
10:36:16FromGitter<alehander92> no
10:36:21FromGitter<alehander92> you cant await in sync function
10:36:35FromDiscord_<mratsim> ah, that's strange API, I'm confused
10:36:41FromGitter<alehander92> thats how it works
10:36:45FromDiscord_<mratsim> I'll have a cleaner one for multithreading
10:36:53FromGitter<alehander92> because await was long time defined in async
10:37:01FromGitter<alehander92> with await template maybe we can unify
10:37:05FromGitter<alehander92> waitFor and await one day
10:37:11FromGitter<alehander92> good idea for rfc
10:37:14FromDiscord_<mratsim> yeah that would be nice, it's confusing
10:37:32FromGitter<alehander92> it needs a good compile error
10:37:34FromGitter<alehander92> on the other hand i agree
10:37:43FromGitter<alehander92> that its useful to have it as different name
10:37:49FromGitter<alehander92> because await doesnt block and waitFor blocks
10:37:54FromGitter<alehander92> maybe blockWait
10:38:39FromDiscord_<mratsim> > When a procedure is "awaited", the asynchronous procedure it is awaited in will suspend its execution until the awaited procedure's Future completes.
10:38:52FromDiscord_<mratsim> await blocks (otherwise the name is strange)
10:38:57FromGitter<alehander92> no
10:38:59FromDiscord_<Lantos> yeah
10:39:03FromGitter<alehander92> blocking is when it blocks the loop imo
10:39:22FromDiscord_<mratsim> it blocks the async thread
10:39:23FromGitter<alehander92> waiting is when its function code doesnt continue
10:39:34FromGitter<alehander92> thats not how its used usually
10:39:35FromGitter<alehander92> i think
10:39:49FromGitter<alehander92> usually in async/await blocking is when something blocks the loop
10:39:50FromGitter<alehander92> iirc
10:39:52FromDiscord_<Lantos> could you write an example?
10:39:53FromGitter<alehander92> but i might be wrong
10:39:55FromDiscord_<mratsim> your async code will not block the spawner when you await
10:40:03FromDiscord_<mratsim> but within the async context it's blocked
10:40:08FromGitter<alehander92> mratsim stay with me, we are talking about async/await
10:40:13FromGitter<alehander92> without multithreading yet
10:40:19FromDiscord_<mratsim> that's the same
10:40:34FromGitter<alehander92> but "blocking" the async context
10:40:36FromGitter<alehander92> is called waiting
10:40:38FromGitter<alehander92> not blocking
10:40:41FromGitter<alehander92> i think
10:40:54FromDiscord_<mratsim> when you async, you spawn a next execution context. You main execution context continues untl it hits a waitFor
10:41:07FromGitter<alehander92> no
10:41:07FromDiscord_<mratsim> at a waitFor, it blocks until the futures completes
10:41:17FromGitter<alehander92> it continues until a loop switch
10:41:20FromGitter<alehander92> i think
10:41:29FromGitter<alehander92> i am not sure if switches happen only with waitFor
10:41:37FromGitter<alehander92> event loop switch*
10:41:52FromGitter<alehander92> think about it, what is useful to know
10:42:04FromGitter<alehander92> is if something blocks the entire loop and other contexts
10:42:16FromGitter<alehander92> waiting for await is the normal thing to do in a context
10:42:23FromGitter<alehander92> its not really sensible to call it the same
10:42:30FromDiscord_<mratsim> Now, in the new execution context you do your async thing, until you create another one with async, or you block that execution context with await
10:42:30FromGitter<alehander92> because on the opposite
10:42:33FromGitter<alehander92> when you await
10:42:35FromGitter<alehander92> you unblock
10:42:51FromGitter<alehander92> mratsim, this is just confusing sorry
10:42:58FromGitter<alehander92> when you await
10:43:03FromGitter<alehander92> you unblock the event loop
10:43:16FromDiscord_<mratsim> but you block the execution context
10:43:18FromGitter<alehander92> giving back to it and letting it run your AND other context
10:43:26FromGitter<alehander92> but mratsim this isnt called blocking
10:43:30FromGitter<alehander92> its called
10:43:32FromGitter<alehander92> awaiting
10:43:33FromDiscord_<mratsim> when you develop you don't think about event loop, you think about your program flow
10:43:36FromGitter<alehander92> thats why its called await
10:43:40FromGitter<alehander92> eh no?
10:43:50FromGitter<alehander92> you have to keep in mind when you can block
10:43:53FromGitter<alehander92> thats the reason
10:44:04FromGitter<alehander92> i wanted to even have type checking for blocking operations
10:44:09FromGitter<alehander92> (maybe other people did too)
10:44:29FromGitter<alehander92> because you can easily call some blocking io without thinking deep somewhere
10:44:36FromGitter<alehander92> and not realize it blocks your whole loop
10:44:41FromDiscord_<Lantos> did I poke the hive?
10:44:43FromDiscord_<mratsim> The whole reason for async/await imo is to abstract away that.
10:44:52FromDiscord_<mratsim> I think it's more a question of semantics
10:45:26FromGitter<alehander92> yes it is i agree and sorry
10:45:32FromDiscord_<mratsim> you program as you would for serial but you notify the compiler when you can do your thing on the side (async) and when you need the result (await/waitFor)
10:45:35FromGitter<alehander92> you're right that it is a kind of "blocking"
10:45:41FromGitter<alehander92> but i am just saying that this is not
10:45:45FromGitter<alehander92> how people use this word
10:45:47FromGitter<alehander92> today
10:45:52FromGitter<alehander92> in programming
10:46:22FromGitter<alehander92> so to not have confusion between
10:46:29FromGitter<alehander92> event loop blocking / scheduler blocking
10:46:34FromDiscord_<mratsim> anyway, I'm back to debugging the bug that has been haunting me for 3 days :/
10:46:34FromGitter<alehander92> and context "blocking"
10:46:35*LargeEpsilon joined #nim
10:46:39FromGitter<alehander92> we call the next one awaiting
10:46:55FromGitter<alehander92> https://stackoverflow.com/questions/2625493/asynchronous-vs-non-blocking
10:47:11FromDiscord_<mratsim> I think asyncdispatch would need that in the documentation so that we have a more precise vocabulary when talking
10:47:44FromGitter<alehander92> yes, i might be wrong yet
10:47:53FromGitter<alehander92> but i think thats how i read it until now
10:49:03FromGitter<alehander92> i cant find a good resource as a source tho
10:51:14FromDiscord_<mratsim> anyway sorry for the digression @Lantos, that doesn't change what you need to do to fix
10:51:30FromDiscord_<mratsim> waitFor in the main proc, and await in the async proc
10:52:25*couven92 quit (Read error: Connection reset by peer)
10:52:52*couven92 joined #nim
10:56:13*uu91 quit (Read error: Connection reset by peer)
10:56:36*uu91 joined #nim
10:57:54FromGitter<alehander92> sorry mratsim
10:58:02FromDiscord_<Lantos> on the semantics of waitFor blockWaitFor
10:58:02FromDiscord_<Lantos> would it not be easier to have wait and await
10:58:02FromDiscord_<Lantos> wait: syncronous
10:58:02FromDiscord_<Lantos> await: asyncro
10:59:07FromDiscord_<Lantos> https://play.nim-lang.org/#ix=22BD
11:01:10*letto joined #nim
11:12:58enthus1astdoes someone know how to peek on a process output stream?
11:13:36enthus1astit fails with "cannot retrieve file position"
11:16:16*endragor joined #nim
11:19:53*nsf quit (Quit: WeeChat 2.6)
11:21:08*endragor quit (Ping timeout: 245 seconds)
11:28:01*ftsf quit (Ping timeout: 265 seconds)
11:29:40*ng0 quit (Ping timeout: 260 seconds)
11:37:43lqdev[m]enthus1ast: I don't think that's possible, since stdout/stderr are not buffers like files, but rather continuous streams of data which cannot be seeked
11:39:06enthus1astmy issue is, i'm trying to use the in and out streams in an async context, which failes cause the read blocks
11:40:02enthus1astso my suspision is that this will not work out :/
11:42:47*ng0 joined #nim
11:53:33FromGitter<alehander92> Lantos maybe
11:53:42FromGitter<alehander92> sounds good in theory
11:59:32*LargeEpsilon quit (Ping timeout: 246 seconds)
12:04:01FromDiscord_<mratsim> @enthus1st you need to create an actual thread for console that's true in any language, but some hides it from you
12:05:01enthus1astso one thread reads, one threads writes and channels the bytes back to may program?
12:05:07enthus1astmy
12:16:05*nif_ quit (Quit: ...)
12:16:15*nif joined #nim
12:16:36*Trustable joined #nim
12:40:49*krux02 joined #nim
12:48:19*krux02 quit (Remote host closed the connection)
12:54:29*narimiran quit (Quit: leaving)
13:09:07*solitudesf joined #nim
13:11:42*fanta1 joined #nim
13:25:14*tklohna quit (Ping timeout: 276 seconds)
13:27:42*Hideki_ quit (Remote host closed the connection)
13:28:27*Hideki_ joined #nim
13:29:39*theelous3 joined #nim
13:30:32*nsf joined #nim
13:32:48*Hideki_ quit (Ping timeout: 245 seconds)
13:33:26*Hideki_ joined #nim
13:37:12*Trustable quit (Remote host closed the connection)
13:40:02*Hideki_ quit (Ping timeout: 240 seconds)
13:50:33FromDiscord_<IanIAnIAN> is there a 1.0* equivalent of import unsigned?
13:54:05*Hideki_ joined #nim
13:55:44*ng0 quit (Ping timeout: 260 seconds)
13:59:02*Hideki_ quit (Ping timeout: 276 seconds)
14:03:56*Hideki_ joined #nim
14:04:06disruptekin the latest 1.0, you shouldn't need it.
14:11:06FromDiscord_<IanIAnIAN> Just noticed this comedy error
14:11:06FromDiscord_<IanIAnIAN> https://cdn.discordapp.com/attachments/371759389889003532/647801294915895326/unknown.png
14:12:17*clyybber joined #nim
14:13:34FromDiscord_<IanIAnIAN> when a language is new and the person responsible for tagging new items for the catalog has no clue
14:17:11*Hideki_ quit (Ping timeout: 265 seconds)
14:19:11lqdev[m]guess it's time to go on a crusade
14:19:38lqdev[m]but first, we need to find whoever was responsible for this heresy
14:20:43FromDiscord_<IanIAnIAN> What if we find it is Dominik himself?
14:21:05*Hideki_ joined #nim
14:21:07lqdev[m]there's no way he would do that!
14:21:59FromDiscord_<IanIAnIAN> That's just what he wants you to think
14:25:54*Hideki_ quit (Ping timeout: 240 seconds)
14:25:54lqdev[m]…or does he? jake chudnow - moon men plays
14:26:44clyybberAraq: Regarding static as return type, wdym this is not how you design type systems?
14:28:10*NimBot joined #nim
14:29:08disruptekclyybber: to design type systems, Araq uses a goat, a full moon, and the blood of a virgin.
14:29:25clyybberromantic
14:40:16livcdenthus1ast:
14:46:15*Hideki_ joined #nim
14:55:28FromDiscord_<Rika> uh, was that supposed to contain a message?
14:56:12Araqclyybber: I figured it out, --gc:arc works with our most complex example so far now
14:56:40clyybberAraq: Nice!
14:57:37Araqbut the bad news is that my cycle breaker was responsible
14:57:48clyybberAraq: Now we just leak right?
14:57:55clyybberWith a cycle
14:57:59clyybberinstead of crashing
14:58:21Araqright. well .cursor exists but breaking up these cycles manually is a lost cause
14:58:38Araqthe resulting topology is inexplicable
14:59:04Araqclosures are too messed up
14:59:27disruptekgc:arc json benchmark 2.9s and 2.07 with default; 2.09 with mark & sweep.
15:00:05Araqdisruptek: json misses some important annotations though
15:00:34disruptekit's just an early number so we can see how it gets quicker. 😉
15:00:57AraqI usually get it down to "beats the old stuff" after a bit of tweaking
15:01:47disruptekbase64 doesn't build due to req repr.
15:02:00Araqwtf
15:02:10Araqrepr is a debugging tool, the stdlib shouldn't use it
15:02:16disruptekagree.
15:02:32disruptekline 193.
15:02:43disruptek"Invalid base64 format character " & repr(s[inputIndex]) &
15:04:26disruptekit's in httpclient, too.
15:04:55Araqfix it please
15:04:55disruptekand other modules. ugh.
15:05:43disruptekit'll be breaking, but i'll pr.
15:06:15Araqwatch out, macros.repr is fine
15:07:00clyybberdisruptek: But its only changing the error messages right?
15:07:08clyybberSo its not really breaking any working code
15:07:12Araqyeah and it's only these 2 places
15:07:31Araqclyybber: anyway, looks like we need this trial deletion via =trace idea
15:07:34disruptekwho knows how people are using outputs as inputs.
15:08:06Araqdisruptek: it'll be fine but we won't backport it
15:08:11disruptekright.
15:08:22clyybberAraq: Yeah.
15:08:49Araqclyybber: or we come up with a creative way of copying closure environments if we were to introduce a cycle
15:08:53clyybberBtw, some static bugs, for your pleasure https://github.com/nim-lang/Nim/issues/12713
15:08:56disbot^ A few bugs related to static parameters
15:08:56disbot^ snippet at https://play.nim-lang.org/#ix=22E4 😏
15:09:14clyybberAraq: Huh, how would that work?
15:09:44Araqyou turn x.field = x into x.field = deepCopy(x)
15:10:20Araqroughly, it'll change the semantics
15:10:44clyybberso you want to try to statically prevent introducing cycles?
15:13:47*tklohna joined #nim
15:19:37clyybberAraq
15:20:09Araqthat's another possibility, but I'm talking of disarming dangerous potentially introducing cycles via deepcopy
15:20:55clyybberHmm, but for stuff that must be cyclic and relies on that, that would infinitely deepcopy until all memory is full
15:21:12clyybberIts like unrolling a while(true) loop
15:21:25*fildon joined #nim
15:22:48Araqthat's not how it works
15:23:00Araqit works more like "copy on write"
15:23:17disruptekneat.
15:24:15Araqbut it changes the semantics in subtle ways, hard to understand the consequences, might as well enforce 'owned' then which at least puts the burden at compiletime
15:25:06disruptekmaybe it needs a `strict` option.
15:26:37Araqwell I think it's time to try =trace
15:27:45*sagax quit (Ping timeout: 265 seconds)
15:29:30clyybbersolitudesf: Will you put xcm in the void repos?
15:29:39*sagax joined #nim
15:30:02*tklohna quit (Ping timeout: 276 seconds)
15:31:27solitudesfi dont think they need programs with ~0 users in repos
15:31:45disruptekbase64 bench is 4.3s with gc:arc, 1.5s without.
15:31:48clyybbermaybe that will change once its in the repos
15:31:53clyybberit seems handy
15:32:39solitudesfwell, i found very crucial flaw with it, so i dont want to push it anywhere until i rework it
15:32:46clyybberah ok
15:34:35*narimiran joined #nim
15:36:32*fildon quit (Quit: Leaving)
15:37:40livcdso...who is good at making bindings ?
15:37:55clyybberwhat bindings?
15:40:35livcdclyybber: nim bindings for a c++ lib
15:42:02clyybberuh, c++ bindings.. didn't attempt that yet
15:42:05clyybberwhat lib?
15:43:09*ng0 joined #nim
15:43:11livcdclyybber: https://github.com/sciter-sdk/nsciter
15:45:47*dddddd joined #nim
15:46:15Araqdisruptek: for gc:arc you really should use 'nim cpp'
15:46:20*kevin5 joined #nim
15:46:22disruptekokay.
15:46:47clyybberlivcd: DOes it not work anymore?
15:46:56clyybberAraq: Why?
15:47:27Araqclyybber: we wrap every proc in a try-finally which becomes a setjmp
15:47:46clyybberAh, right
15:49:28*ng0 quit (Quit: Alexa, when is the end of world?)
15:49:55livcdclyybber: nope. Both sciter and Nim had changed
15:50:39*narimiran quit (Remote host closed the connection)
15:51:19*narimiran joined #nim
15:51:33*ng0 joined #nim
15:52:15livcdclyybber: but it seems pretty complicated because of Tiscript and whatnot :/
15:52:55clyybberhmm, gl fixing it
15:53:47clyybbercan't help you with sciter :(
15:55:34ZevvWell, my Nim native async MQTT library ended up tons smaller then all existing ones I found wrapping native C libs
15:57:27disruptekZevv: you can solve the `getint8()` problem with get[int8]() or get[T](default: T): T.
15:57:59*FromGitter quit (Remote host closed the connection)
15:58:17*FromGitter joined #nim
15:58:55*couven92 quit (Read error: Connection reset by peer)
15:59:21*couven92 joined #nim
16:07:28Zevvoh right, thats slightly better
16:09:26livcdclyybber: probably only shashlick is the right person
16:09:38clyybberyeah
16:09:52disrupteknimterop isn't quite ready for c++ wrappers.
16:13:45shashlick@livcd looks like it has a plain C api as well
16:13:57shashlickBut not sure if that's sufficient for you
16:16:42*tklohna joined #nim
16:17:01livcdwell i only wrapped some winapi so far. Never anything on a scale like this
16:18:11shashlickI'm asking cause nimterop can handle C just fine
16:18:25shashlickBut if you want C++ then ya
16:20:48livcdhmm dont rellay know if it's sufficient
16:24:28*Hideki_ quit (Remote host closed the connection)
16:24:38FromDiscord_<exelotl> @demotomohiro oh wow thanks, that does actually show up
16:25:16*Hideki_ joined #nim
16:28:16FromDiscord_<exelotl> OH my call to glGenBuffers was wrong
16:29:56FromDiscord_<exelotl> was passing the address of my vertex data rather than the address of the integer to hold the ID
16:31:33*Hideki_ quit (Ping timeout: 265 seconds)
16:31:40*bacterio quit (Write error: Connection reset by peer)
16:36:55*krux02 joined #nim
16:38:12FromDiscord_<onelivesleft> I have a `quote do:` block inside a macro, and inside it I am defining a proc. if I do `proc parse() = ` it works fine, but I want to set the name of the proc to a const defined in the outer scope. I thought I could do `proc 'PROC_NAME'() = ` but that treats PROC_NAME as a quoted string. Is there a way to do this?
16:38:30FromDiscord_<onelivesleft> (I'm using backticks, I just changed them to singlequote for discord formatting)
16:40:49FromDiscord_<exelotl> @onelivesleft I tend to do something like this: https://hastebin.com/obomepejad.nim
16:44:05FromDiscord_<onelivesleft> perfect, ty
16:48:01FromDiscord_<exelotl> np
16:48:15*Hideki_ joined #nim
16:50:27enthus1astlivcd: ?
16:52:17*Hideki_ quit (Ping timeout: 240 seconds)
16:54:13*kevin5 quit (Remote host closed the connection)
16:59:20FromDiscord_<exelotl> can't decide whether to use vmath or glm
17:00:34FromDiscord_<exelotl> glm seems more powerful, vmath seems more human and easier to work with
17:01:19disruptekhumans are overrated.
17:08:50FromDiscord_<Rika> i went with glm
17:16:10FromDiscord_<mratsim> I underestimated lock-free and multithreading bugs. Finally solved a Multi-Producer Single-Consumer channel Heisenbug when I tried to rewrite my channel as lock-free after 4 days.
17:17:47clyybberkrux02: Thanks for your explanation on the static parameter issue
17:18:30krux02np
17:19:16krux02clyybber: what I am interested in, how did you get to the idea that you had? What was the motivation?
17:20:01clyybberThe motivation was more or less that I didn't know if it made a difference wether I use a static param in a compileTime proc or not
17:21:05clyybberAnd the motivation for having static as a return type preferred over {.compileTime.} was that it seems to fit better into the existing static handling
17:21:19clyybberBut I guess in the end it doesn't matter.
17:21:41clyybberBut I think a {.static.} alias for {.compileTime.} would be a good idea.
17:22:00clyybberAnd I think {.compileTime.} variables should be compile time only but thats another story
17:23:16FromDiscord_<exelotl> oh.. I updated glm (from 1.1.1 to 1.1.1) and now the compiler crashes on quat.nim
17:23:36disruptekquite an upgrade.
17:24:01FromDiscord_<exelotl> yeah
17:28:13Zevvdisruptek: what are you doing here? werent you supposed to be lost in mountainous wildlands?
17:29:11disruptekgot hungry.
17:29:28clyybberhunt a moose then
17:29:32clyybber*get hunted by moose
17:32:01disruptekwould rather hunt bugs.
17:32:11clyybberbugs haunt me
17:32:38clyybberbugs in my code that is
17:38:14*db93858 is now known as madprops
17:39:12*minierolls quit (Quit: WeeChat 2.4)
17:42:25FromDiscord_<IanIAnIAN> stop coding bugs then
17:42:37FromDiscord_<Rika> *stop coding then
17:42:53disruptekin soviet russia, bugs hunt you.
17:43:18FromDiscord_<Rika> i wish tests wrote themselves
17:43:25clyybberTIL coding == soviet russia
17:48:55*couven92 quit (Read error: Connection reset by peer)
17:49:18*couven92 joined #nim
17:57:26livcdenthus1ast: did you ever make the windows service work ?
17:58:54krux02clyybber: Regarding "And I think {.compileTime.} variables should be compile time only but thats another story". I think so, too. It also was like that in the past. When it was changed I made clear that I was against that change.
17:59:10krux02Now {.compileTime.} means different things depending on the context.
17:59:30disruptekyeah, i don't like that, either.
17:59:54krux02for procs it means compile time evaluation only, for vars it means, enable compileTime usage besides runtime usage.
18:00:10FromDiscord_<exelotl> I tried messing around with the behaviour of {.compileTime.} at runtime and it makes no sense to me lol
18:01:28*sealmove quit (Quit: WeeChat 2.6)
18:01:59Araqwell it's not enough to disagree with my design, you need to come up with a better one. ideally also one that's not a pita to implement and doesn't end up in sophistry
18:02:02*joshbaptiste joined #nim
18:02:14krux02disruptek, clyybber: here is the PR
18:02:15Araqand there were no alternative proposals.
18:02:16krux02https://github.com/nim-lang/Nim/pull/12128
18:02:17disbot -- allows access to .compileTime vars at runtime
18:03:02disruptekhmm, maybe merged PRs should be purple.
18:03:29FromDiscord_<exelotl> https://play.nim-lang.org/#ix=22ET
18:03:44krux02Araq: I can not always drop everything I do and write a proposal for a problem, whenever you have a bad idea that I know will cause problems in the long run.
18:04:49krux02I can offer you hower to review your proposals.
18:05:48krux02But there was no proposal, we discussed this, I told you the problems I had with it, but instead of rethinking the idea, you just went ahead and dismissend my criticism.
18:07:35FromDiscord_<exelotl> changes made to a {.compileTime.} variable at compile-time have no effect on the value at runtime (so you can't put the variable into some useful initial state during compilation)
18:07:38FromDiscord_<Rika> i dont understand why compileTime variables should be accessible in runtime
18:07:45FromDiscord_<exelotl> you can *sometimes* mutate a {.compileTime.} variable at runtime but not always (i.e. you can change individual fields but can't reassign it)
18:08:01FromDiscord_<exelotl> and yeah, what Rika said, I don't really see what it's trying to achieve
18:08:04FromDiscord_<Rika> rather, readable is understandable
18:08:09FromDiscord_<Rika> but modifiable?
18:08:34FromDiscord_<Rika> and its kinda misleading that it's called compileTime but can be read on runtime
18:09:10clyybberIt should be called {.static.} and they should be only accessable like a static expression.
18:09:17clyybberMeaning no modification at runtime
18:09:28clyybberAnd no location at runtime
18:09:37clyybber(no address)
18:09:45krux02clyybber: back to the alias compileTime/static, I also don't think that this alias is a good idea. Beacause static really means something else, I told you about the function specialization. You can also combine static parameters with functions that are supposed to be evaluated on the nimvm. Then the functions are specialized on the nimvm.
18:10:49clyybberHmm, but clearly the type of an expression such as `someCompileTimeProc()` is `static T`
18:11:16krux02Maybe we should have annotations such as ``{.target: nimvm.}`` instead of ``{.compileTime.}``, because it makes clear that this compile time evaluation is actually just another backand, one that happens to be evaluated at compile time.
18:11:33krux02clyybber: no it is not.
18:11:51FromDiscord_<Generic> but nimvm is also used for nimscript
18:11:59FromDiscord_<Generic> all the time
18:12:01clyybberkrux02: What is it then?
18:12:43krux02``static T`` is not a type, it is some annotation for function parameters, nothing else.
18:13:08clyybberIt is a type modifier
18:13:13clyybberTheres tyStatic
18:13:26clyybberAnd it makes sense to have static at the type level
18:13:37krux02a parameter ``static T`` means that for any expression ``f(x)`` must be known when that call is compiled.
18:13:44clyybberFor example compile time variables would then just have the type `static T`
18:14:11krux02no I really don't like that.
18:14:14clyybberAnd `static T` can be used for `T` as an immutable const expression
18:14:32krux02I prefer if the type stays at T, no wrapping static around it.
18:14:32disruptekyeah.
18:15:00clyybberkrux02: AFAIK this is what zah was aiming for though
18:15:11disrupteki think it's more like taint.
18:15:18disruptekor color.
18:15:28krux02I think `statically known` is something orthogonal to the type, it should not wrap the type.
18:16:04disruptekyou think static T is distinct from T?
18:16:09clyybberYeah
18:16:16clyybberstatic T can be used as T
18:16:47krux02clyybber, that is exactly what I am worried about.
18:17:13disruptekwhat's the danger?
18:17:49krux02it type refection in macros, static T will look very different to T. It would be very annoying when all of the sudden I have to implement in all my macros that handle types this additional case: "type can be tyStatic" that I need to peel off otherwise it would just not work."
18:18:26krux02I don't want to peel of the static in all my macros.
18:19:36krux02it is already anoying enough that I have to peel of this annoying typedecs everywhere to get to the actual type.
18:19:54krux02combine that with tyStatic and you ge all sorts of combinations
18:19:59clyybberHmm
18:20:05krux02static[typedesc[T]]
18:20:14clyybberthats stupid
18:20:14krux02typedesc[static[T]]
18:20:17clyybbernope
18:20:28clyybberstatic doesn't work like that
18:20:44clyybberit should work like var; only occur at the start of a type
18:20:50clyybberouter shell
18:21:09krux02that is what I call orthogonal
18:22:09krux02I would like to not see it in any ast that I get from getTypeInst or getTypeImpl
18:22:22clyybberkrux02: Yeah thats understandable
18:22:35clyybberIt shouldn't appear to macros
18:22:41clyybberunless specifically asked for
18:22:49clyybberlike isStatic
18:22:52clyybberor something like that
18:23:04krux02I agree
18:23:40clyybberkrux02: Cool, so we only disagreed about the terminology :)
18:23:50krux02yea
18:23:57*couven92 quit (Read error: Connection reset by peer)
18:23:59krux02I think so
18:24:20*couven92 joined #nim
18:24:36krux02I also don't really like the term `static` because it is overused and means a lot of different things to different people.
18:25:53clyybberBut it is what we have and IMO it fits.
18:25:55krux02compileTime is also not good, because evaluating somithing in the nimvm is technically compileTime but it is runtime for the vm function
18:26:01clyybberAlthough it doesn't mean the same thing as in other langs
18:26:31krux02I think `static` is ok. I don't have sothing better and I don't think we find something better.
18:26:38clyybberYeah
18:26:46clyybberWe should try to make it as consistent as possible
18:27:11krux02wy goal
18:27:20krux02but someone is working against it.
18:27:32clyybber\o/ :D
18:27:53krux02clyybber: recent consistency break: https://github.com/nim-lang/Nim/issues/12700
18:27:56disbot➥ consistency break between VM and runtime behavior; snippet at 12https://play.nim-lang.org/#ix=22F1 😏
18:28:49clyybberHmm, I saw that one, not sure what the solution would be
18:29:08clyybberMaybe just allow it at compile time too?
18:30:04krux02What I don't like is. I told my complains in the proposal. They were ignored/dismissed, proposal was not adopted. Then the PR was implemented and merged. Then I raised the problems as an issue. And it was instantly closed by Araq.
18:30:34krux02The solution would be to remove the range checks in nimvm and semfold as well
18:31:07krux02I also suggested that in the RFC
18:31:28clyybberYeah thats probably the best idea
18:32:03clyybberThis multi use of uint for different things screams for suint
18:32:20krux02what is suint?
18:32:25clyybbersafe uint
18:32:37clyybbera uint with overflow checks
18:32:58clyybberI invented the name :p
18:33:13clyybberbut it is tricky to implement in C
18:33:17clyybber(if possible at all)
18:33:28krux02I don't really care for save uint. But I think this wrap around behavior in C and range check with error on nimvm is really an unnecessary bad thing
18:33:47clyybberyeah, it should be wraparound everywhere
18:34:07krux02clyybber: there are extensions for C that allow you to see the overflow bit from math operations.
18:34:15clyybberOh, nice
18:34:39clyybberI implemented a POC in inline assembler once (but that was before I knew about Nim)
18:34:48clyybberBecause I didn't know about those extensions
18:35:22krux02http://clang.llvm.org/docs/LanguageExtensions.html#checked-arithmetic-builtins
18:35:42clyybberthanks!
18:35:45*anon234234 joined #nim
18:36:27krux02also supported in gcc
18:36:44krux02microsoft probably has something similar with different names, but not sure about that
18:37:01*fanta1 quit (Ping timeout: 250 seconds)
18:37:01anon234234hey, anyone know why this simple regex isn't working as expected? match seems to only want to match the beginning of the string not anywhere in the middle https://pastebin.com/1HCPPADw
18:37:22clyybberpastebin is down
18:37:29clyybberanon234234: Try it in regex101
18:37:51anon234234the regex works prefect in regex101
18:38:06anon234234doAssert not "testing".match(re"test").isNone # succeeds
18:38:12anon234234doAssert not "testing".match(re"ing").isNone # fails
18:38:21anon234234i expect both of them to work
18:38:41narimiranyou sure that `match` doesn't expect a pattern to be at the start of the string?
18:38:57anon234234hmmm maybe that's it...
18:39:11narimirantry `find` or `search` or whatever is the other function
18:39:55anon234234whoops, ... it is always anchored to the start of the string
18:40:02anon234234find looks like what i need
18:40:10anon234234thanks
18:40:14narimirananon234234: yep, https://play.nim-lang.org/#ix=22F5 works
18:41:55*couven92 quit (Read error: Connection reset by peer)
18:42:23*couven92 joined #nim
18:46:40disruptek#12602
18:46:41disbothttps://github.com/nim-lang/Nim/pull/12602 🠲 6export nim.cfg parser for use by other tools
18:49:06clyybberawesome
19:03:50madpropsso yeah i think there's an issie with having object properties called items
19:03:52madpropsissue
19:04:02madpropsthough not sure
19:12:17*Zevv left #nim ("it hurts, it huuuurts")
19:13:02*xet7 quit (Quit: Leaving)
19:14:44FromDiscord_<kodkuce> https://www.reddit.com/r/rust/comments/e0aq6y/polonius_the_future_rust_borrow_checker_talk_at/ << duno if this helps for new runtime magic
19:15:21FromDiscord_<kodkuce> ps i dident read it at all, just was guessing meybe something nice inthere
19:15:41clyybberYeah, I saw that today too. It looks interesting and fairly simple
19:15:57clyybbernot sure where it would fit in nrt though, since nim employs a very different model
19:16:09blackbeard420hmm when i try to pass a Channel[int] by pointer to a thread all is fine, but it doesnt compile if its a Channel[string]
19:16:32clyybberwhats the error?
19:19:02blackbeard420oh wow nvm, i must of had forgeten to change the Thread[Targ]
19:19:04blackbeard420my bad
19:19:59FromDiscord_<exelotl> is there a way to create a ref array literal?
19:21:10FromDiscord_<exelotl> I have `var vertices = [...]` and now I want to be able to pass around a GC-safe reference to vertices
19:22:32*narimiran quit (Quit: leaving)
19:25:22*narimiran joined #nim
19:28:03*narimiran quit (Client Quit)
19:30:38*narimiran joined #nim
19:34:15*prometheus quit (Remote host closed the connection)
19:34:52FromDiscord_<exelotl> hmm well this works https://play.nim-lang.org/#ix=22Fo
19:55:47disruptek!rfc picasso
19:55:48disbothttps://github.com/nim-lang/RFCs/issues/160 -- 3Project Picasso - A multithreading runtime for Nim
19:56:04disruptek!rfc 173
19:56:05disbothttps://github.com/nim-lang/RFCs/issues/173 -- 3Developing Nim's stdlib and a Nim distribution
19:57:55disruptek!issue base64 author:dom96
19:57:56disbothttps://github.com/nim-lang/Nim/issues/12675 -- 3base64 changes break code
19:57:56disbothttps://github.com/nim-lang/Nim/issues/3223 -- 5base64 assert failure on decode
19:58:43FromGitter<Willyboar> Disruptek we need a help or list command
19:58:49disruptektry !help
19:58:59FromGitter<Willyboar> !help
19:59:00disruptek!pull faster base64
19:59:01clyybberdisruptek: Can it also display PRs of other repos?
19:59:01disbothttps://github.com/nim-lang/Nim/pull/12436 -- 5About 50% faster base64 implementation.
19:59:09disruptekyes.
19:59:18clyybberawesome!!
19:59:20clyybber!help
19:59:26disruptek!search nimble installation golden
19:59:27disbothttps://github.com/disruptek/golden/issues/15 -- 5Nimble Installation Fails
20:00:04disruptekalso, you can /msg disbot directly, as always. i dunno how many people use it that way.
20:00:07clyybber!repo weave pull 21
20:00:07disbotno results 😢
20:00:15disruptek!repo weave
20:00:15disbothttps://github.com/mratsim/weave -- 11A state-of-the-art Message-Passing based, fast, scalable, ultra-low overhead multithreading runtime
20:00:51disruptek!search mratsim/weave 21
20:00:52disbothttps://github.com/bluenote10/NimData/issues/21 -- 3Mean and other operations over columns
20:00:53disbothttps://github.com/ThomasTJdev/nim_websitecreator/issues/21 -- 5Idea: Add optional minimal favicon.ico
20:00:53disbothttps://github.com/numforge/laser/issues/21 -- 3[GEMM] Enhance serial implementation
20:01:08disruptek!search repo:mratsim/weave is:pr 21
20:01:09disbothttps://github.com/mratsim/weave/pull/21 -- 3Change to lockless unbounded mpsc
20:01:10disbothttps://github.com/mratsim/weave/pull/1 -- 5OSX compat
20:01:31dom96cool, now can we get a hoogle-equivalent? :D
20:01:54disruptek!repo disruptek/xs
20:01:54disbothttps://github.com/disruptek/xs -- 11xstreamstartup.com
20:02:19disruptek...has a google client that uses their search api. i guess i could integrate, but why?
20:02:50clyybber!disbot is awesome
20:03:26disruptekalso, PRs are color-coded according to open/closed/merged.
20:03:31disruptek#11560
20:03:32disbothttps://github.com/nim-lang/Nim/pull/11560 🠲 5ISO-26300 Documentation generator rstgen
20:03:35disruptek#5755
20:03:37disbothttps://github.com/nim-lang/Nim/pull/5755 🠲 6Small base64.nim refactor
20:03:47disruptek#12716
20:03:49disbothttps://github.com/nim-lang/Nim/pull/12716 🠲 3replace some runtime repr in stdlib for gc:arc
20:04:42disruptekbut when you're searching for issues, it doesn't bother to determine color (it'd take an extra query per each result).
20:05:02dom96disruptek, do you know what hoogle is?
20:05:12disrupteki thought it was a typo.
20:05:49livcdhmm karax seems more complicated than I thought
20:05:49*nif quit (Quit: ...)
20:05:59*nif joined #nim
20:06:30disruptekif you can get me a swagger definition for hoogle, i'll add it.
20:10:11*dillonb quit (Quit: WeeChat 2.2)
20:13:26*uu91 quit (Ping timeout: 276 seconds)
20:14:11*uu91 joined #nim
20:18:05*nsf quit (Quit: WeeChat 2.6)
20:40:57*couven92 quit (Read error: Connection reset by peer)
20:41:21*couven92 joined #nim
20:44:54*Zevv joined #nim
21:19:58*stefantalpalaru quit (Ping timeout: 252 seconds)
21:26:13clyybbernarimiran: Btw the CIs are failing
21:26:50narimiranclyybber: mention the one who made them fail, not me :P
21:30:01narimiranthis is the commit which is causing trouble: https://github.com/nim-lang/Nim/commit/8b2f8f5430e8c328efe5bce94e397f15e3c501af
21:31:53clyybbernarimiran: I think its unrelated, thats why I tagged you :p
21:32:34narimiranthe commit before it was green :/
21:33:09clyybberhmm, but take a look at this: https://hastebin.com/odohevofux.js
21:34:18clyybberit only occurs on CI, not locally
21:34:27clyybbernot for me at least..
21:36:08narimiranworks for me too
21:37:18narimiran(but i'm several commits behind the latest devel)
21:37:23disruptekyeah, i also tried to repro it and couldn't.
21:38:50clyybbergoogling that error pulls up a stackoverflow question where someone had that error with docker
21:39:01clyybberMaybe bash isn't preinstalled anymore on azure containers?
21:39:25narimiranok, that might be
21:39:49enthus1astlivcd: i've recently tested windows service with threads but it is indeed crashing maybe i'll invest some time to make it work. I'm useing nssm for my current project...
21:39:59disruptekyeah, 'cause that's base syntax.
21:40:04disruptekbash, too.
21:40:42narimiranbut on the other hand, look at azure-pipelines.yml
21:41:15narimiranwe heavily rely on 'bash' for running quite a lot of things
21:42:22narimirani can try to make a PR where i explicitly install bash, just to be sure that is(n't) the problem
21:42:23enthus1astlivcd: maybe it's already enough for some kind of "restarter watchdog" / "start process with system rights" thing
21:43:02narimiranthe other solution is to disable that test and see if things are passing without it :)
21:44:30disruptekfeels like it's actually due to something one step removed, like a .profile or an env that isn't copied or something.
21:47:49narimiranmaybe some additional `ProcessOption` needs to be passed to `execCmdEx`
21:50:34narimiranfor now i disabled that test in my branch to see if that will make things green
21:50:54narimiranfor anything more than that, it'll have to wait until tomorrow, i'm going to bed now
21:53:01*Jesin quit (Quit: Leaving)
21:54:11*solitudesf quit (Ping timeout: 250 seconds)
21:55:01*Jesin joined #nim
21:56:04clyybbergn8 narimiran
22:00:12*stefantalpalaru joined #nim
22:03:17*narimiran quit (Ping timeout: 250 seconds)
22:11:53*uu91 quit (Read error: Connection reset by peer)
22:12:12*uu91 joined #nim
22:22:14*uu91 quit (Read error: Connection reset by peer)
22:22:40*uu91 joined #nim
22:24:56*clyybber quit (Quit: WeeChat 2.6)
22:34:24*stefantalpalaru quit (Changing host)
22:34:24*stefantalpalaru joined #nim
22:47:38*anon234234 quit (Remote host closed the connection)
22:59:18*uu91 quit (Read error: Connection reset by peer)
22:59:31*uu91 joined #nim
23:05:22*ng0 quit (Remote host closed the connection)
23:06:32*ng0 joined #nim
23:09:35*stefantalpalaru quit (Ping timeout: 250 seconds)
23:20:13*couven92 quit (Quit: Client Disconnecting)
23:57:04*sealmove joined #nim