<< 13-06-2017 >>
00:06:50*yglukhov joined #nim
00:11:10*yglukhov quit (Ping timeout: 240 seconds)
00:21:51*yingjun joined #nim
00:22:57*gokr quit (Ping timeout: 240 seconds)
00:25:50*yingjun quit (Ping timeout: 240 seconds)
00:31:00*yglukhov joined #nim
00:35:10*yglukhov quit (Ping timeout: 240 seconds)
00:35:29skrylardom96, i dunno
00:35:42skrylarAs a lapsed apple fanboy I have to say they have an impossible task
00:36:44skrylarThere's a lot of weird crap that happens and they have to manage it. Like when companies get blamed for stuff individuals do.
00:37:17skrylarIf people are wildly using the vibrate function for no reason, people start blaming things that *aren't* the program doing it. Which messes with perception.
00:37:40skrylarI don't usually like how they manage it, although they seem to acknowledge that their solutions suck anymore
00:39:03skrylarIt might just be nice if there was an official "I am not a moron" flag that was like really specific to turn on so it wasn't used in scams but didn't require all the drmy crap. but i have to food now, so i leave
00:39:16*skrylar quit (Quit: Leaving)
00:39:20FromGitter<Varriount> On android, rogue popup ads abuse the ability to vibrate
00:55:20*yglukhov joined #nim
00:59:30*yglukhov quit (Ping timeout: 240 seconds)
01:03:30*arnetheduck quit (Ping timeout: 240 seconds)
01:18:47*chemist69 quit (Ping timeout: 246 seconds)
01:19:35*yglukhov joined #nim
01:23:50*yglukhov quit (Ping timeout: 240 seconds)
01:32:47*chemist69 joined #nim
01:38:39*def-pri-pub joined #nim
01:43:53*yglukhov joined #nim
01:48:10*yglukhov quit (Ping timeout: 240 seconds)
02:02:37*yglukhov joined #nim
02:03:04libmanhttps://www.reddit.com/r/Python/comments/6gwv4a/a_glance_at_the_pythonlookalike_nim_programming/
02:03:14*zachcarter quit (Quit: zachcarter)
02:05:46*yingjun joined #nim
02:06:57*yglukhov quit (Ping timeout: 240 seconds)
02:15:04*girvo joined #nim
02:34:34*pilne quit (Remote host closed the connection)
02:51:08*yglukhov joined #nim
02:56:05*yglukhov quit (Ping timeout: 268 seconds)
03:08:24*def-pri-pub quit (Quit: leaving)
03:11:44*girvo quit (Ping timeout: 260 seconds)
03:15:50*yglukhov joined #nim
03:20:45*yglukhov quit (Ping timeout: 268 seconds)
03:20:58*yingjun quit (Remote host closed the connection)
03:21:26*yingjun joined #nim
03:35:21FromGitter<Varriount> @zacharycarter So what was required to get plugins working?
03:51:57*yglukhov joined #nim
03:56:05*yglukhov quit (Ping timeout: 240 seconds)
04:03:26*mosORadi joined #nim
04:16:28*yglukhov joined #nim
04:16:41*rauss quit (Quit: WeeChat 1.8)
04:17:13*Snircle quit (Quit: Textual IRC Client: www.textualapp.com)
04:17:32*rauss joined #nim
04:20:35*yglukhov quit (Ping timeout: 240 seconds)
04:21:58*adel joined #nim
04:22:19*adel quit (Client Quit)
04:22:41*nimmerino joined #nim
04:25:14nimmerinoI'm having trouble install nimsuggest on Arch Linux.I installed nim using pacman (`pacman -S nim`), and ran into the bug https://github.com/nim-lang/Nim/issues/5867, so I downgraded to 0.16.0. I have nimble 0.8.4, also from the package manager.
04:27:09nimmerinonimsuggest does not seem to have a binary installed, and I've tried installing nimsuggest with nimble (`nimble install nimsuggest`) but it fails. Logs: https://gist.github.com/anonymous/ebedb0fed13a2cf7973dbf11862063e8
04:29:07nimmerinoI've searched around, and seems like I either need to use koch (?) or install nim from sources which I'd rather not do so it's managed by my package manager
04:39:33*girvo joined #nim
04:52:41*yglukhov joined #nim
04:52:41*yingjun quit (Remote host closed the connection)
04:53:02*yingjun joined #nim
04:54:26*yingjun quit (Remote host closed the connection)
04:57:04*yglukhov quit (Ping timeout: 246 seconds)
05:00:16*yingjun joined #nim
05:00:18*vlad1777d joined #nim
05:14:48Araqnimmerino: just install from source
05:17:10*yglukhov joined #nim
05:21:13*yglukhov quit (Ping timeout: 246 seconds)
05:26:46*Vladar joined #nim
05:26:50*chemist69 quit (Ping timeout: 240 seconds)
05:27:00nimmerinoAraq: any idea what the problem is due to? Is there something that can be done about the Arch Linux package, especially since it seems to be an officially endorsed installation method?
05:27:58Araqwell the Arch Linux package could ship with nimsuggest out of the box
05:35:30nimmerinoalright, I installed from source and everything works now, thanks. was hoping for a more elegant solution but it's alright
05:35:49*myp joined #nim
05:45:22*chemist69 joined #nim
05:53:21*yglukhov joined #nim
05:57:27*yglukhov quit (Ping timeout: 240 seconds)
06:12:31*mosORadi quit (Quit: Connection closed for inactivity)
06:14:47*nsf joined #nim
06:15:26*yingjun quit (Remote host closed the connection)
06:15:47*yingjun joined #nim
06:16:45*yingjun quit (Remote host closed the connection)
06:24:53*Demosthenex joined #nim
06:25:23Demosthenexi just saw a blog mentioning that nim had a TUI in the standard library, yet doing 5 minutes of searches and skimming modules i can't find it. anyone know what it was referring to?
06:25:24*yingjun joined #nim
06:35:55def-Demosthenex: this? https://nim-lang.org/docs/terminal.html
06:43:47euantorFor whoever it was that was creating an AWS module, this may be a good read: https://matthewkmayer.github.io/blag/public/post/rusoto-codegen/
06:44:33*girvo quit (Ping timeout: 260 seconds)
06:48:29*gokr joined #nim
06:48:33*libman quit (Quit: Connection closed for inactivity)
06:50:34ftsfhmm how would I do a deep clone of a ref object while preserving its type?
06:53:04ftsfdeepCopy*[T](x: var T, y: T) has no return... and not documented what the y arg is for
06:54:21Araqvar x: ref T; deepCopy(x, mysourceRef)
06:54:28Araqshould work
06:54:49ftsfahh, docs say "performs a deep copy of x"
06:54:58ftsfbut sounds like it performs a deep copy of y and puts it in x then?
07:00:09*Arrrr joined #nim
07:00:09*Arrrr quit (Changing host)
07:00:09*Arrrr joined #nim
07:04:55FromGitter<Varriount> euantor: I'm not having any problems interpreting the JSON files from botocore. It's the backend details that are tricky (authentication and parsing).
07:16:59*xet7 joined #nim
07:18:34*yglukhov joined #nim
07:22:04*girvo joined #nim
07:22:29*girvo quit (Client Quit)
07:22:56*yglukhov quit (Ping timeout: 255 seconds)
07:25:22Demosthenexdef-: unfortunately that's not a TUI lib. that's just curses style screen manipulation
07:25:53*yingjun quit (Remote host closed the connection)
07:26:05*yingjun joined #nim
07:26:09Demosthenexdef-: turbovision was a TUI lib.
07:28:46*yingjun quit (Remote host closed the connection)
07:28:55*yingjun joined #nim
07:29:53*yingjun quit (Remote host closed the connection)
07:30:55def-Demosthenex: I know, I'm just saying that's the closest I've seen in the standard lib
07:32:46*yglukhov joined #nim
07:35:37ArrrrMmm, 1k issues
07:42:24FromGitter<andreaferretti> I see there are a lot of useful PR just waiting to be merged
07:42:33FromGitter<andreaferretti> I know review is a lot of work
07:42:57FromGitter<andreaferretti> but is there a particular reason why they are all being postponed?
07:43:10FromGitter<andreaferretti> eventually they will become unmergeable and that would be a pity
07:45:11*nimmerino quit (Ping timeout: 246 seconds)
07:55:09euantorVarriount: Ahh, sorry I misunderstood what you were saying the other day then :)
07:55:59Araqftsf: the parameter names could be better but the 'var T' part is unambiguous and so it's like assignment and copyMem, dest comes first
07:56:06*yglukhov quit (Remote host closed the connection)
07:56:15FromGitter<Varriount> @andreaferretti Only Araq and Zahary have the experience to review compiler-related PRs
07:57:02FromGitter<Varriount> dom96 go through the rest when we can
07:57:11FromGitter<Varriount> *dom96 and I
07:57:12*yglukhov joined #nim
08:00:49*JStoker quit (K-Lined)
08:01:22*yingjun joined #nim
08:04:56FromGitter<andreaferretti> Sure, I know everyone has a lot to do
08:05:10FromGitter<andreaferretti> It is just that there are some easy one that could be merged quickly
08:05:14FromGitter<andreaferretti> For instance
08:05:14*JStoker joined #nim
08:05:15FromGitter<andreaferretti> https://github.com/nim-lang/Nim/pull/5941
08:06:16FromGitter<andreaferretti> https://github.com/nim-lang/Nim/pull/5778
08:06:59FromGitter<andreaferretti> https://github.com/nim-lang/Nim/pull/5952
08:08:08FromGitter<andreaferretti> https://github.com/nim-lang/Nim/pull/5831
08:09:33FromGitter<andreaferretti> They seem like easy wins
08:10:46FromGitter<andreaferretti> https://github.com/nim-lang/Nim/pull/5866
08:12:03*yglukhov quit (Remote host closed the connection)
08:12:13FromGitter<Varriount> @andreaferretti Going through them now. Thanks!
08:12:52FromGitter<andreaferretti> :-)
08:14:19FromGitter<Varriount> @andreaferretti Those with contributor access should probably organize some sort of meeting to go through all those PRs. Some of them are big enough to need consensus decisions.
08:15:13AraqI merged the one that I could merge fwiw
08:17:25*yglukhov joined #nim
08:18:43FromGitter<Varriount> @andreaferretti You any good with makefiles? I'm not qualified to review https://github.com/nim-lang/Nim/pull/5830 , which https://github.com/nim-lang/Nim/pull/5866 depends on.
08:21:24Araqha, same here, but def- is around
08:21:40*yglukhov quit (Ping timeout: 240 seconds)
08:23:03FromGitter<Varriount> @andreaferretti Additions to the standard library are also tricky... there's already enough ad-hoc/poorly thought-out procedures hanging around, no-one wants to introduce more.
08:23:12FromGitter<andreaferretti> I see
08:23:17*FromGitter * Varriount looks at HttpHeaders
08:23:25FromGitter<andreaferretti> But then maybe it would be better to rject quickly
08:23:41FromGitter<andreaferretti> It is just that seeing all these PRs which look forgotten
08:23:52FromGitter<andreaferretti> Is a little demoralizing
08:24:10FromGitter<Varriount> A good half of them are waiting on submitter responses
08:24:11FromGitter<andreaferretti> About the makefiles: unfortunately I am not very familiar :-(
08:25:35*yglukhov joined #nim
08:29:29Demosthenexdef-: yeah, i got excited when i read that blog post saying that the nim language had a TUI in the standard lib. I haven't seen that since Turbovision in Turbo Pascal...
08:29:44Demosthenexdef-: unfortunately, curses emulation !- TUI, just like perl, python, and other langs.
08:30:10Demosthenexdef-: for a hobbyist programmer who abhors GUIs and webapps, a recent TUI lib sounded nice
08:31:56FromGitter<Varriount> @araq https://github.com/nim-lang/Nim/pull/5940 ?
08:33:35Araqwell that one is big :P
08:33:45FromGitter<Varriount> https://github.com/nim-lang/Nim/pull/5908 ?
08:34:02FromGitter<Varriount> That's just adding integer casting to the VM
08:36:43Araqthat's convoluted and a bit wrong
08:41:00Araqhttps://github.com/nim-lang/Nim/pull/5872
08:41:33Araqone problem is that github doesn't notify me on PR changes
08:41:59AraqPR comes along, I review it, give feedback and am not notified when my feedback was taken into account -.-
08:44:13*rusua joined #nim
08:52:14FromGitter<Varriount> @Araq I need to close that one, I have more exhaustive documentation in the works.
09:12:39*yglukhov quit (Remote host closed the connection)
09:13:38*yglukhov joined #nim
09:17:22*yglukhov quit (Remote host closed the connection)
09:22:20*yingjun quit (Remote host closed the connection)
09:22:32*yingjun joined #nim
09:23:28*yingjun quit (Remote host closed the connection)
09:24:56*yglukhov joined #nim
09:26:41*yingjun joined #nim
09:29:13*krux02 joined #nim
09:29:22*yglukhov quit (Ping timeout: 246 seconds)
09:33:52*yglukhov joined #nim
09:45:09*krux02 quit (Remote host closed the connection)
09:45:35*krux02 joined #nim
09:48:08*couven92 joined #nim
09:54:30*krux02- joined #nim
09:54:30*krux02 quit (Disconnected by services)
09:54:32*krux02- is now known as krux02
10:00:02*yglukhov quit (Remote host closed the connection)
10:03:01*yglukhov joined #nim
10:14:41dom96skrylar: Varriount: Firefox on Android asks for permission when an app first tries to vibrate your phone. That's the simple solution and it works well, surprised Chrome doesn't do the same.
10:27:32dom96nimmerino: in case you read the logs: use choosenim to install Nim from source, it'll install nimsuggest for you as well. https://github.com/dom96/choosenim#installation
10:29:06dom96andreaferretti: Pretty sure everyone can review PRs, so if you see easy ones just say so in the PR, better yet approve it using GitHub's review feature and ping one of us.
10:29:51FromGitter<andreaferretti> uh? anyone can review?
10:30:02FromGitter<andreaferretti> did not know that
10:37:05*NimBot joined #nim
10:37:36*yglukhov quit (Remote host closed the connection)
10:37:49*yglukhov joined #nim
10:43:00*couven92 quit (Quit: Client disconnecting)
10:47:18AraqNim snippet of the week:
10:47:20Araqtemplate `[]`(n: Node; x: int): pointer = keyAt(n, x, b.layout)
10:48:02Araqa template that turns an ugly ternary accessor into an array notation
10:48:36Araqno other language can do this, afaik
10:52:08ArrrrWhat's the context? Also, would be nice to have a "snippet of the day" section, we could sumbit our own snippets.
10:55:12AraqI'm writing a low-level BTree implementation where address computations that usually are done by the compiler can't be done because they are only known at runtime
10:55:31Araqand yet I can use the syntax a[i] everywhere :-)
10:56:14dom96Can't pretty much any language with operator overloading do this?
10:57:45FromGitter<krux02> Araq: what do you say about reverting the breaking change of the do notation?
10:58:34Araqdom96: but you can't mask the access to the local 'b.layout' without templates
10:59:35Araqkrux02: I'm slightly in favour of it but think the 'do' notation just needs to die.
10:59:39Araqfoo:
10:59:41Araq bodyA
10:59:42Araqdo:
10:59:44Araq bodyB
11:00:05Araq'do' is like 'else' a statement continuation so that multiple bodies can be passed to foo
11:00:23Araqfoo do: bodyA is unnecessary and should go away.
11:00:51ArrrrThen quote should not require `do`
11:01:09FromGitter<krux02> sounds good to me, but quite currently has an optional argument
11:01:49AraqArrrr: I think with the new parser we can make 'quote' work without 'do' easily
11:02:04FromGitter<krux02> if would be nice then, when I can use statement continuation a bit more flexible then
11:02:27Araqkrux02 is your 'sizeof' PR ready?
11:02:33AraqI want it :-)
11:03:45FromGitter<krux02> Well as far as my tests go, it is correct, the only problem is, for types that are packed, the generated C code creates types that are not packed correctly and therefore my generated offsets and sizes are not correct
11:03:55FromGitter<krux02> eg
11:05:05FromGitter<krux02> ``````
11:06:22FromGitter<krux02> when I have the equivalent of that as packed, then the packedness does not propagate tho the inner struct yz, therefore z gets padding bytes for alignment, but that alignment is not going to help, because the struct is shifted by one byte because of x.
11:06:30FromGitter<krux02> I created an issue for that
11:06:41Araqcan you just bail out for .packed stuff?
11:06:52Araqlike we do today for any complex objects?
11:07:37krux02https://github.com/nim-lang/Nim/issues/5824
11:08:00krux02what yo you mean with "bail out"
11:08:52krux02I think, you mean to emit C backend code?
11:09:16Araqwell right now the compiler says "cannot evaluate at compile-time"
11:09:30Araqit can continue to do this for packed objects
11:10:27krux02Well kind of, but I removed all bail out code from that branch because my goal was to handle all cases at compile time
11:11:03*dom96 has been in favour of getting rid of the do notation for a long time
11:11:05krux02In other words I would need to reintroduce some of the bail out code
11:11:17dom96Does this also include the 'do' notation as used for closures?
11:11:57krux02btw I am also not a huge fan of the do notation either, but the do notation allowed me to pass any block of code to a function expression at the end of a line
11:12:04krux02very usable
11:12:15krux02but the fact that there was a do, was never necessary for me
11:12:29krux02but back to packed objects
11:13:24krux02Araq: how much effort do you think would it be to emit recursively the __packed__ attribute to structs in C?
11:13:41krux02I just don't know where to do it, but I can imagine that it isn't too much effort
11:13:54Araqkrux02: sounds easy, let me have a look
11:15:04*yglukhov quit (Remote host closed the connection)
11:16:09*yglukhov joined #nim
11:18:37Araqkrux02: are only case objects affected?
11:21:54*yglukhov quit (Remote host closed the connection)
11:22:06*yglukhov joined #nim
11:26:30*Neomex joined #nim
11:28:46*xet7 quit (Remote host closed the connection)
11:32:23*yglukhov quit (Remote host closed the connection)
11:35:55krux02Araq: as far as I know, yes
11:36:27krux02I don't know any case where embedded structs are generated other than case objects
11:37:04krux02or better said anonymous structs
11:38:15*Snircle joined #nim
11:40:52krux02Is there an official list of keywords in nim?
11:46:12*yingjun quit (Remote host closed the connection)
11:47:24*xet7 joined #nim
11:47:25Araqhttps://nim-lang.org/docs/manual.html#lexical-analysis-identifiers-keywords
11:47:30Araqkrux02: ok, I fixed it
11:51:46Araqandreaferretti: so how can I reproduce your bug?
11:52:05Araqwhich OS? can I use the one OS with good CUDA support? *cough*
11:53:47*couven92 joined #nim
11:54:44FromGitter<Varriount> Araq: New parser?
11:55:07Araqvarriount: no, just grammar/parser changes really
11:55:18Araqand they are all in 0.17.0
11:59:52*yglukhov joined #nim
12:05:45FromGitter<andreaferretti> @Araq I am using Ubuntu 16.04, but I guess anything with CUDA support will do
12:06:12FromGitter<andreaferretti> I am going through a few old issues, mainly to figure out which one should be closed
12:06:21Araqare you sure it's not simply a double free on your side?
12:07:29FromGitter<andreaferretti> Well, one can never be sure, but the finalizer has a nil check for this purpose
12:07:45FromGitter<andreaferretti> ```proc freeDeviceMemory[A](p: ref[ptr A]) = ⏎ if not p[].isNil: ⏎ check cudaFree(p[])``` [https://gitter.im/nim-lang/Nim?at=593fd590f31c8ced0c2f77c7]
12:08:17FromGitter<andreaferretti> Moreover, the finalizer is only called as a finalizer
12:08:22FromGitter<andreaferretti> I never call it manually
12:08:38FromGitter<andreaferretti> I guess the ref count should go down to 0 just once
12:09:02Araqthe nil check is worthless
12:09:09FromGitter<andreaferretti> but the weird thing is that the error appears (apparently) in a part of code that tries to *locate* the finalizer
12:09:17FromGitter<andreaferretti> why is it worthless?
12:09:36Araqbecause the pointer might be duplicated and freed
12:10:01FromGitter<andreaferretti> the only procedure that calls `cudaFree` is the finalizer
12:10:03Araqvar x = alloc(); var y = x; dealloc(y); if x != nil: dealloc(x)
12:10:18Araqyes, but the finalizers share the pointer
12:10:24Araqwell *might* share
12:10:59Araqis your cudaAlloc paired with Nim's new?
12:11:08Araqif not, that's your problem
12:11:11FromGitter<andreaferretti> well, if `p` is of type `ref[ptr[A]]` and I copy it, I think I should copy the `ref`
12:11:37FromGitter<andreaferretti> getting different refs pointing to the same raw pointer
12:12:08Araqwell that cannot work.
12:12:13FromGitter<andreaferretti> they are indeed paired, here https://github.com/unicredit/neo/blob/master/neo/cudadense.nim#L45-L47
12:12:18FromGitter<krux02> afaik finalizers are a bit problematic in nim, because I found cases, where they weren't called at all. (if we are talking about the same stuff)
12:12:28FromGitter<andreaferretti> and here template init*A (v: CudaMatrix[A], m, n: int) = ⏎ new v.data, freeDeviceMemory ⏎ v.fp = cudaMallocA (m * n)
12:12:38FromGitter<andreaferretti> oops https://github.com/unicredit/neo/blob/master/neo/cudadense.nim#L52-L54
12:12:51FromGitter<andreaferretti> why it cannot work?
12:13:03FromGitter<andreaferretti> the idea is that the pointers I get from CUDA are raw pointers
12:13:09FromGitter<andreaferretti> I wrap them into a ref
12:13:27FromGitter<andreaferretti> when the ref is finally collected
12:13:37FromGitter<andreaferretti> at that point I also collect the raw pointer
12:13:42FromGitter<andreaferretti> seems safe to me
12:16:04Araqok, so if they are paired there is no need for your isNil check
12:17:02FromGitter<andreaferretti> Yeah, in fact it was not there at the beginning
12:17:19FromGitter<andreaferretti> I added it as a double check
12:17:46shmup
12:18:13Araqhttps://github.com/nim-lang/Nim/issues/4851 is it this bug?
12:22:15FromGitter<andreaferretti> I cannot tell for sure, but it may be related
12:22:27FromGitter<andreaferretti> Still, I don't think I am allocating
12:23:20FromGitter<andreaferretti> Well, I could be allocating a new exception if the cuda call fails
12:24:06FromGitter<andreaferretti> but the line where this points https://github.com/nim-lang/Nim/blob/devel/lib/system/gc.nim#L245 makes this look like the GC is not able to figure out the finalizer for the type
12:25:11FromGitter<andreaferretti> uh, maybe I understand what is going on
12:25:38FromGitter<andreaferretti> As I said, the mechanism is used to refcount CUDA pointers
12:25:59FromGitter<andreaferretti> So it happens that I create a new object copying the `ref`
12:26:13FromGitter<andreaferretti> like here https://github.com/unicredit/neo/blob/master/neo/cudadense.nim#L134
12:26:35krux02Araq: I just rebased the sizeof-alignof branch on the new devel branch and the test I wrote passes
12:26:56krux02That doesn't mean that everything is perfect, but it looks good
12:27:27FromGitter<andreaferretti> In this case, can it be possible that the finalizer is not correctly associated with the ref pointer (because I did not used `new` + finalizer)?
12:29:20Araqno, that's not possible, the finalizer is added the RTTI
12:29:39Araqdo you use 'new' without a finalizer somewhere for the same type`
12:29:40Araq?
12:30:30FromGitter<andreaferretti> no, in fact I only use `new` inside the template I linked above
12:30:50FromGitter<andreaferretti> there is only one place to initialize -> less space for errors
12:31:46Araqyeah in fact, your design looks really nice -.-
12:31:58AraqI wonder what we're missing
12:33:36FromGitter<andreaferretti> I can try to reproduce a small example that does not involve CUDA
12:34:08FromGitter<andreaferretti> I can use the same pattern and write a program that just keeps allocating in a cycle
12:34:35FromGitter<andreaferretti> Not sure if it will appear, but it's worth a try
12:38:57Araqyeah please do that
12:39:53*Arrrr quit (Read error: Connection reset by peer)
12:45:33FromGitter<zacharycarter> I have some questions about shared memory and threads - first of all, are channels still considered slow - or is the abstraction that they buy you worth it over manual memory management?
12:46:50*yingjun joined #nim
12:48:04FromGitter<zacharycarter> next question - I have a sequence of ref objects that I want to share between threads. what all do I need to allocate in shared memory? anything that wouldn't be allocated on the stack? so if the ref object has a string member - do I need to allocate that in shared memory as well if I want to access it in another threads?
12:48:07FromGitter<zacharycarter> thread*
12:48:41*couven92 quit (Quit: Disconnecting)
12:48:57FromGitter<zacharycarter> or will createShared(foo) do that for me?
12:49:04FromGitter<zacharycarter> if foo is the ref object in question
12:51:03*rauss quit (Quit: WeeChat 1.8)
12:51:28*yingjun quit (Ping timeout: 260 seconds)
12:52:09Araqzacharycarter: you need to use protect/dispose for every GC'ed thing within your 'ptr'
12:53:45FromGitter<zacharycarter> Araq: thanks
12:54:27FromGitter<zacharycarter> channels sound way easier than managing all those locks
12:59:54*yglukhov quit (Remote host closed the connection)
13:02:40FromGitter<krux02> my recommendation as well
13:03:00FromGitter<krux02> managing locks sound to me like a process where a lot of things can easily get wrong
13:09:25*krux02 quit (Remote host closed the connection)
13:09:27FromGitter<Varriount> Araq: What are protect/dispose supposed to do? They aren't documented.
13:11:25*krux02 joined #nim
13:12:49Araqvarriount: that's a pity, but they are threadsafe GC_ref/GC_unref variants
13:13:03*krux02 quit (Disconnected by services)
13:13:04*krux02- joined #nim
13:13:07*krux02- is now known as krux02
13:13:20*krux02 quit (Disconnected by services)
13:13:20*krux02- joined #nim
13:13:22*krux02- is now known as krux02
13:13:34*krux02 quit (Disconnected by services)
13:13:35*krux02- joined #nim
13:13:38*krux02- is now known as krux02
13:13:49*krux02 quit (Disconnected by services)
13:13:50*krux02- joined #nim
13:13:53*krux02- is now known as krux02
13:14:38FromGitter<Varriount> Hm. So the pointer being passed in doesn't need to one the "current" heap owns?
13:14:53*yglukhov joined #nim
13:22:39*yglukhov quit (Remote host closed the connection)
13:28:58*yglukhov joined #nim
13:34:59*Demosthenex left #nim (#nim)
13:51:42*rauss joined #nim
14:00:21*yglukhov quit (Remote host closed the connection)
14:03:37*yglukhov joined #nim
14:12:21*yglukhov quit (Remote host closed the connection)
14:14:59*yglukhov joined #nim
14:37:17*nsf quit (Quit: WeeChat 1.7.1)
14:50:23*yingjun joined #nim
14:54:31*yingjun quit (Ping timeout: 246 seconds)
15:00:24*yglukhov quit (Remote host closed the connection)
15:00:51*heinrich5991 quit (Quit: quit.)
15:03:36*yglukhov joined #nim
15:05:39*yglukhov quit (Read error: Connection reset by peer)
15:05:43*yglukhov_ joined #nim
15:06:34FromGitter<TiberiumN> Hi everyone ! what's the simplest way to extract LZMA compressed byte stream? ⏎ Preferably crossplatform
15:06:34*yglukhov_ quit (Read error: Connection reset by peer)
15:06:44FromGitter<TiberiumN> (not a file, but a stream in memory)
15:06:46*yglukhov joined #nim
15:08:57FromGitter<TiberiumN> I'm parsing game replay, and after some fields I have a chunk of LZMA data (as string)
15:10:43*xet7 quit (Quit: Leaving)
15:11:09*yglukhov quit (Ping timeout: 240 seconds)
15:12:09*Neomex quit (Quit: Leaving)
15:14:49*Arrrr joined #nim
15:21:32*heinrich5991 joined #nim
15:26:04*Trustable joined #nim
15:41:35dom96TiberiumN: hrm, maybe you could use gzip? There is a wrapper somewhere.
15:46:27*vlad1777d quit (Ping timeout: 260 seconds)
15:50:27FromGitter<TiberiumN> dom96: it seems that gzip format is different from lzma
15:50:46FromGitter<TiberiumN> I found a wrapper to "zip" library: https://github.com/nim-lang/zip
15:50:58FromGitter<TiberiumN> maybe it can decompress lzma
15:51:38dom96Maybe you could wrap this? https://lloyd.github.io/easylzma/
15:51:58dom96but yeah, I think gzip might support it
16:00:19*yglukhov joined #nim
16:01:43*nsf joined #nim
16:04:35*yglukhov quit (Ping timeout: 240 seconds)
16:07:25*vlad1777d joined #nim
16:19:11*yglukhov joined #nim
16:20:13FromGitter<TiberiumN> dom96: yeah, thanks for easylzma, I also found a fork of it with fixed memory leaks and simple.h header (because I only need 1 function to decompress anyway)
16:20:14FromGitter<TiberiumN> https://github.com/TransitApp/easylzma
16:37:22dom96Maybe you could even port it to nim
16:38:06FromGitter<TiberiumN> Port whole algorhitm?
16:40:03dom96sure
16:52:20*yingjun joined #nim
16:56:47*yingjun quit (Ping timeout: 246 seconds)
17:10:33FromGitter<TiberiumN> I think I can't port whole algorhitm for now, but I have an issue with C compilation of simple.c in https://github.com/TransitApp/easylzma ⏎ ⏎ I want to have one executable
17:10:45FromGitter<TiberiumN> {.compile: "simple.c"} at the start of the file can't help
17:10:47*pilne joined #nim
17:10:53FromGitter<TiberiumN> Even if I moved all .h and .c files in one folder
17:11:06*xet7 joined #nim
17:11:26FromGitter<TiberiumN> so simple.c includes all other files, but compiler still can't find them
17:11:29FromGitter<TiberiumN> (it's not a nim issue)
17:17:54FromGitter<TiberiumN> anyway, I've made hacky solution
17:27:56*kunev quit (Ping timeout: 246 seconds)
17:30:20*kunev joined #nim
17:36:58*yglukhov quit (Remote host closed the connection)
17:37:41*yglukhov joined #nim
18:03:27*nimmerino joined #nim
18:11:18Arrrruse emit and copy everything
18:12:29demi-Araq: just want to say thank you (and to the other language maintainers) for keeping the syntax lean and simple. greatly appreciate the clarity of this language compared to some others i have to work in
18:13:45Araqdemi-: oh thanks :-) fortunately the syntax fights seem to be over (ignoring the 'do' notation)
18:22:45*nimmerino quit (Remote host closed the connection)
18:22:54*nimmerino joined #nim
18:27:36Arrrrthe do notation for anonymous procs should not be strong typed, otherwise it takes almost the same number of characters that takes to type it with the 'simpler' proc: https://pastebin.com/tRiNtyvg
18:37:16FromGitter<Varriount> Arrr: How would overloads work then?
18:37:40FromGitter<Varriount> I mean, suppose 'trigger' takes more than one kind of procedural type as an argument
18:39:35ArrrrWell, in that case you would have to resort to anonymous proc without the do. Right now, it does the same thing for the same price, unless i'm mistaken
18:46:30*krux02 quit (Remote host closed the connection)
18:47:55Araqyou're mistaken, 'do' works without types too
18:50:48ArrrrCompiler must be in the wrong too, because it doesn't allow me
18:53:20Araqmaybe I deprecated and removed it because future.=> should be used instead
18:57:02ArrrrAh well, in that case for one line is actually better: `trigger((a, b) => a + b)`
19:01:20*yingjun joined #nim
19:05:28*yingjun quit (Ping timeout: 240 seconds)
19:16:50*nsf quit (Quit: WeeChat 1.7.1)
19:20:04*adam] is now known as ada[m]
19:22:35*Arrrr quit (Ping timeout: 240 seconds)
19:27:56*ofelas joined #nim
19:28:05*yglukhov quit (Read error: Connection reset by peer)
19:28:55*yglukhov joined #nim
20:02:51*vendethiel joined #nim
20:03:12*yglukhov quit (Remote host closed the connection)
20:03:36*Matthias247 joined #nim
20:03:47*yglukhov joined #nim
20:07:53*yglukhov quit (Ping timeout: 246 seconds)
20:11:45*yglukhov joined #nim
20:29:02*Jesin quit (Quit: Leaving)
20:31:44*Jesin joined #nim
20:33:00*Trustable quit (Remote host closed the connection)
20:38:53*Tiberium joined #nim
20:43:34*Tiberium quit (Remote host closed the connection)
20:49:37*Tiberium joined #nim
21:03:12*yingjun joined #nim
21:07:07*rauss quit (Quit: WeeChat 1.8)
21:07:30*yingjun quit (Ping timeout: 240 seconds)
21:08:55*Tiberium quit (Remote host closed the connection)
21:10:04*gokr quit (Ping timeout: 246 seconds)
21:10:45*gokr joined #nim
21:11:46*nsf joined #nim
21:14:34FromGitter<zacharycarter> hrm
21:14:48FromGitter<zacharycarter> I'm trying to send a message between channels that contains a sequence of ref objects
21:15:08FromGitter<zacharycarter> is this possible? my app just hangs
21:17:18*Vladar quit (Quit: Leaving)
21:17:49dom96it should be
21:17:58dom96are you sure it's not hanging because the channel is empty?
21:18:19FromGitter<zacharycarter> pretty sure
21:18:59FromGitter<zacharycarter> going to do some more testing - if I instantiate the ref object by itself and don't reference the sequence I'm trying to pass in it works
21:20:05*nsf quit (Quit: WeeChat 1.7.1)
21:21:08dyce[m]Little bit off topic, what laptop do you use for development?
21:21:10FromGitter<zacharycarter> I'm binding to another dynamic library to produce the ref object
21:21:14FromGitter<zacharycarter> macbook pro
21:21:48dyce[m]My brother sat on my MacBook pro retina 2012, RIP
21:24:21FromGitter<zacharycarter> dom96: any idea if the situation I'm describing would break things?
21:24:31*xet7 quit (Quit: Leaving)
21:25:23dom96zacharycarter: No idea I'm afraid
21:25:32dom96Araq: ^
21:26:16dom96I do have a weird hunch that channels don't support refs at all
21:26:24dom96but I'm not sure if I'm just misremembering
21:26:33FromGitter<zacharycarter> they seem to
21:26:56FromGitter<zacharycarter> but this ref has a bunch of function pointers assigned to it AND it's passed from another DLL
21:32:16*nimmerino quit (Quit: Konversation terminated!)
21:32:24FromGitter<zacharycarter> think I might know why
21:32:46Araqdom96: refs are deepcopied but are supported
21:33:23FromGitter<zacharycarter> inheritance?
21:34:31FromGitter<zacharycarter> Araq: what I'm doing is kind of weird - I'm trying to build a hot reloadable plugin system - so I have plugins defined such as this: https://gist.github.com/zacharycarter/ca9769d2466e346bee42e84691cfbbdc
21:35:13FromGitter<zacharycarter> I then have another module which is responsible for checking on this file - compiling it and then dynlib.loading it at runtime when it changes
21:35:56FromGitter<zacharycarter> I'm using another thread to do the file watching and I was trying to pass the plugins themselves (Game in this case) via channels to that thread
21:40:42FromGitter<zacharycarter> things are just locking up though, can't figure out why
21:43:26FromGitter<zacharycarter> I've pretty much narrowed it down to the FFI though I think
21:43:28*PMunch joined #nim
21:52:34FromGitter<zacharycarter> bleh
22:05:26*Neomex joined #nim
22:08:59*nightmared quit (Ping timeout: 255 seconds)
22:12:38*ofelas quit (Quit: shutdown -h now)
22:16:16FromGitter<zacharycarter> Araq: https://gist.github.com/zacharycarter/603a7c6e47538b146d2373061216788b
22:16:21FromGitter<zacharycarter> minimal as I can get I think
22:19:06*Snircle quit (Quit: Textual IRC Client: www.textualapp.com)
22:24:36*Snircle joined #nim
22:25:24Araqtold you to use nimrtl
22:25:32FromGitter<zacharycarter> thought I was
22:26:16FromGitter<zacharycarter> oh doh sorry apparently I can't read
22:29:48*gokr quit (Ping timeout: 240 seconds)
22:34:29FromGitter<zacharycarter> alright now I'm compiling with plugin with : nim c -d:useNimRtl --app:lib pluginimpl.nim
22:34:37FromGitter<zacharycarter> linking to libnimrtl.dylib
22:35:01FromGitter<zacharycarter> app locks up immediately
22:35:05*PMunch quit (Quit: leaving)
22:43:09Araqyou need to compile both with -d:useNimRtl and even then, just write your game. Unix's DLLs are just not worth the trouble
22:44:06FromGitter<zacharycarter> hrm :/ -d:useNimRtl doesn't work with threads
22:48:46*Matthias247 quit (Read error: Connection reset by peer)
22:56:24Araqthat's been reported...
23:01:25FromGitter<zacharycarter> yeah I know - I was focused on working on this plugin system first and building the engine around that
23:01:39FromGitter<zacharycarter> sounds like it's a bad idea though
23:04:57*yingjun joined #nim
23:05:21*def-pri-pub joined #nim
23:09:27*yingjun quit (Ping timeout: 240 seconds)
23:25:14*yglukhov quit (Remote host closed the connection)
23:50:11*rauss joined #nim