<< 01-04-2019 >>
00:10:34*ghidra joined #nim
00:42:44*a_b_m quit (Quit: Leaving)
00:46:41*theelous3_ quit (Ping timeout: 268 seconds)
01:11:04*arecacea1 quit (Remote host closed the connection)
01:11:23*arecacea1 joined #nim
01:15:37I_Right_ISo I published my multi threaded UDP Library if anyone wants to try it out. Bare in mind its my first nim library and first time managing a git repo.
01:15:39I_Right_Ihttps://github.com/i-right-i/simpleUDP
01:27:19FromDiscord<exelotl> sealmove: thanks :)
02:02:24*ikan-keli_ quit (Ping timeout: 255 seconds)
02:06:02*banc quit (Quit: Bye)
02:07:27FromGitter<kayabaNerve> I_Right_I: You didn't actually upload the lib
02:07:54FromGitter<kayabaNerve> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5ca1727af851ee043d3ede6c]
02:13:43*ikan-keli_ joined #nim
02:26:38I_Right_IkayabaNerve: you should be able to install with --> nimble install https://github.com/i-right-i/simpleUDP
02:26:57*banc joined #nim
03:11:11FromGitter<gogolxdong> Hi, @I_Right_I
03:11:28FromGitter<gogolxdong> Have you consider make it QUIC?
03:24:24I_Right_IUnless I am mistaken QUIC uses UDP at its core.
03:25:17*noeontheend joined #nim
03:26:26I_Right_ISo as I learn nim I plan on making protocal libraries that us the core simple UDP
03:26:50I_Right_Iprotocol^
03:29:13FromGitter<gogolxdong> Glad you know QUIC. Your library is a good start.
03:37:59FromGitter<kayabaNerve> I_Right_I https://github.com/i-right-i/simpleUDP/blob/master/src/simpleUDP.nim
03:38:22FromGitter<kayabaNerve> Your example imports this file. This file doesn't have functional code in it.
03:38:29FromGitter<kayabaNerve> I was trying to tell you that,
03:39:01FromGitter<kayabaNerve> QUIC is an UDP overlay that offers TCP functionality with UDP efficiency.
03:39:52FromGitter<kayabaNerve> I still need to add UDP to my code base :thinking:. We currently use TCP for everything when I want to use a mix. I MIGHT end up doing QUIC/UDP, once QUIC is more available, or just QUIC.
03:40:54I_Right_Ioh I am new to managing git,
03:42:07I_Right_Ione sec
03:44:09I_Right_Iokay that should do it
03:44:49I_Right_IWhen I test it it installed and built
03:45:26I_Right_Iwould you mind testing it
03:51:21I_Right_Iso I still had some debug stuff in it from when I was having problems with threadpools
03:59:41*Snircle quit (Quit: Textual IRC Client: www.textualapp.com)
04:34:33I_Right_IkayabaNerve: What do you plan on using QUIC for
04:35:38*nsf joined #nim
04:38:00FromGitter<kayabaNerve> Nothing as of right now; planning on TCP + UDP, but will do tests with QUIC and UDP, and if those go well, QUIC alone.
04:38:08FromGitter<kayabaNerve> I'm a cryptocurrency developer, so P2P networks.
04:39:17FromGitter<gogolxdong> Do you have a plan to improve kademlia by QUIC?
04:43:25I_Right_IkayabaNerve: So have you done any network stuff with nim?
04:45:13FromGitter<kayabaNerve> Entire codebase is in Nim
05:00:00*noeontheend_ joined #nim
05:03:59I_Right_II think I got the library in working order, at least for now. Did anyone test it?
05:17:52I_Right_IIs there any plan to add htonll() to nims stdlib?
05:21:07*noeontheend_ quit (Ping timeout: 250 seconds)
05:21:07*noeontheend quit (Ping timeout: 250 seconds)
05:32:07*vlad1777d joined #nim
05:40:38*I_Right_I quit (Remote host closed the connection)
05:46:05*ghidra quit (Ping timeout: 256 seconds)
05:54:00*dddddd quit (Remote host closed the connection)
05:59:11*narimiran joined #nim
06:02:36leorizeI_Right_I have you looked at the endians module?
06:14:12*krux02 joined #nim
06:19:46*solitudesf joined #nim
06:51:29*PMunch joined #nim
06:53:10PMunchThis is getting ridiculous.. I had to wade to over my knees in snow this morning just to get out of the house..
06:53:54krux02PMunch, here it is sunny and warm
06:54:49narimiranPMunch: haha, you almost got me there ;)
06:58:40PMunchnarimiran, I wish I was kidding: www.nordlys.no/vis/direkte/cjtxzbduk000009a2381qe3q7?height=500&mode=live
06:58:58PMunchhttps://www.nordlys.no
06:59:07narimiranstill don't believe neither you nor your links :P
06:59:42PMunchThat's the local newspaper, pretty much just stories about how all the roads are closed and how various car crashes
07:00:00*gmpreussner quit (Quit: kthxbye)
07:00:52narimiranwe also have local newspapers faking news on this day, even in print
07:01:03*narimiran trusts no one
07:01:42PMunchOh yeah, we do that here too
07:02:19PMunchHow about statistic metereological data: www.yr.no/place/Norway/Troms/Tromsø/Tromsø_observation_site/almanakk.html
07:03:13PMunch158cm at 7am, was 97cm on Friday
07:03:25FromGitter<mratsim> @gogolxdong we are developing a native Nim implementation of libp2p (the lib behind IPFS) so we'll have Kademlia + QUIC in time
07:03:30narimiranok, i guess it is not that the whole country agreed to prank on strangers living in warmer parts of europe.... :D
07:03:52PMunchnarimiran, to be fair thought that would've been an awesome prank :P
07:04:56*gmpreussner joined #nim
07:05:23Zevvoh is it that time of the year again. *sigh*
07:07:13krux02stack overflow looks nice today
07:07:30krux02it was yesteday
07:07:31krux02hmm
07:27:18PMunchZevv, April 1st?
07:44:25Zevvyes. It seems my kids were not properly awake this morning, so I got away with that. They've been saving pranks from the Beano for weeks, so I'll get the full load when I get home
07:50:05FromGitter<gogolxdong> @mratsim good to know
07:50:14*absolutejam quit (Quit: WeeChat 1.9.1)
07:52:05FromGitter<gogolxdong> QUIC makes Kademlia more practical .Can you foresee what QUIC brings except efficiency?
07:55:33*ng0 joined #nim
08:08:29*stefanos82 joined #nim
08:12:48*floppydh joined #nim
08:25:42*Vladar joined #nim
08:27:55*vlad1777d quit (Remote host closed the connection)
08:28:55*vlad1777d joined #nim
08:41:59*couven92 joined #nim
08:49:39*neceve joined #nim
08:49:53*CcxWrk quit (Killed (verne.freenode.net (Nickname regained by services)))
08:49:54*CcxWrk joined #nim
08:50:15FromGitter<alehander42> Araq, i guess the plans for no gc are for e.g. 2.0
08:50:31*solitudesf quit (Ping timeout: 246 seconds)
08:53:54Araqthat's the most likely outcome
08:54:08Araqwell not "most likely", but it has a good chance
08:54:17livcdand when is 1.0 going to be released ?
08:55:10Araqwe're working on the regressions to get 0.20 out
08:56:04FromGitter<alehander42> ill try to understand this owned ref thing better today
08:58:06*tdc joined #nim
09:02:49Araqyou all act like I'm mad, replacing the tried and proven way with some experimental crap.
09:03:05Araqhttps://github.com/nim-lang/Nim/issues/10858 aliasing bug caused by 'ref'
09:04:10*d10n-work joined #nim
09:14:06FromGitter<alehander42> well, replacing it would be strange indeed, having it as a powerful alternative would be very cool tho
09:14:38FromGitter<alehander42> but i am talking based on assumptions, i'll read more first
09:14:49Araqhere is what a GC does: It turns use-after-free bugs into "reads of outdated data"
09:15:28Araqhere is what type-specific allocation does: it turns them into "reads of newer data"
09:15:43Araqwhere is the evidence that's so much worse to do?
09:15:54Araqthere isn't any.
09:16:29FromGitter<alehander42> maybe that's true
09:17:05FromGitter<alehander42> but if you have two relatively == options, you shouldn't choose the one that changes all current assumptions how certain parts of the language works
09:17:28FromGitter<alehander42> but maybe the pro-s are much more, again, i'll try to see how it applies in some real world example
09:27:34*lritter joined #nim
09:42:45sealmovealehander42: the merit would be to avoid bifurcation
09:43:48sealmoveGC maintainance costs too, though if Boehm does become the default, maybe that's not an issue
09:56:03*vlad1777d quit (Remote host closed the connection)
09:57:01*vlad1777d joined #nim
10:02:35*kapil____ joined #nim
10:05:29*arecacea1 quit (Remote host closed the connection)
10:05:48*arecacea1 joined #nim
10:11:59*sealmove quit (Quit: WeeChat 2.4)
10:42:40Araqhttps://www.infoq.com/interviews/click-0xdata fyi
10:46:30FromGitter<mratsim> Is that about GC, seems to be machine learning + Hadoop
10:49:29AraqCliff Click always talks about GCs.
10:49:40Araqthe topic doesn't matter. :P
10:51:23FromGitter<mratsim> It's curious because H20 he is talking about is not 0xData, and it's also a R company not Java :P
11:10:12*theelous3_ joined #nim
11:49:04*Snircle joined #nim
12:30:03*tdc quit (Quit: Leaving)
12:49:46*oculux joined #nim
13:01:09*kapil____ quit (Quit: Connection closed for inactivity)
13:02:46*dddddd_ joined #nim
13:07:01*dddddd_ is now known as dddddd
13:44:16*noonien joined #nim
13:56:39*noeontheend_ joined #nim
13:56:39*noeontheend joined #nim
14:13:21*PMunch quit (Remote host closed the connection)
14:25:24*Bob- quit (Ping timeout: 250 seconds)
14:30:58*bobby joined #nim
14:35:47*theelous3_ quit (Ping timeout: 250 seconds)
14:43:05*Trustable joined #nim
14:55:01FromGitter<deech> Replying to https://forum.nim-lang.org/t/4754 here since I can't seem to sign up for an account: I looked into Flutter bindings some time ago and the problem is Dart doesn't currently allow 'extern'ing functions/datatypes, so there's no clean way to call Dart from C. Nim callbacks from a Dart main are probably do-able.
14:57:01*noeontheend_ quit (Ping timeout: 250 seconds)
14:57:01*noeontheend quit (Ping timeout: 250 seconds)
15:02:03FromGitter<mratsim> if you're waiting for a confirmation I can bypass that
15:10:18*floppydh quit (Quit: WeeChat 2.4)
15:20:23*noeontheend joined #nim
15:30:18*Trustable quit (Remote host closed the connection)
15:31:20*Trustable joined #nim
15:32:29CcxWrkIs there some convenient macro for calling posix functions and exiting on error with perror()-like message?
15:33:29*shashlick quit (Remote host closed the connection)
15:33:53*shashlick joined #nim
15:35:05FromGitter<mratsim> What do you mean by posix functions? syscall or binaries like "cat", "rm"?
15:36:28CcxWrkposix libc functions as exposed by the posix module; usually returning cint signifying success of the action
15:36:57FromGitter<mratsim> POSIX errors are mapped to errno: https://nim-lang.org/docs/posix.html#errno
15:38:33FromGitter<mratsim> I've not used many posix functions beyond mmap though, it's not hard to wrap them: ⏎ https://github.com/numforge/laser/blob/master/laser/photon_jit/photon_osalloc.nim#L58-L79
15:39:05FromGitter<alehander42> Araq, about " it's detected at runtime if the programmer doesn't understand it. " i think OP gets that, he just expects to be able to prevent this on CT
15:39:11FromGitter<mratsim> there is a lot of examples in the actual Nim low-level code as well
15:40:09*ng0 quit (Quit: Alexa, when is the end of world?)
15:43:09CcxWrkWhat I'm asking is whether there is a premade way to simplify, eg.: if pipe(pipein) != 0: write(stderr, "fatal: pipe(): " & strerror(errno); quit(ERR_PERM) into one statement, or whether should I write one myself.
15:43:32FromGitter<mratsim> Regarding the error message, I don't think there is an easy way with the distinct cint. ⏎ ⏎ With enums you can have better error messages by associating either an enum name to a value ot a string to an enum name
15:43:43FromGitter<mratsim> write one
15:44:20FromGitter<mratsim> or use raise newException(FooError, YourMessage)
15:44:38FromGitter<samdmarshall> @dom96 when you get a chance, i'd like to talk about how to proceed on the `nimble publish` issue I made as I want to make sure everyone has a complete understanding of what i'm attempting to do here.
15:44:41*noeontheend quit (Ping timeout: 250 seconds)
15:44:46FromGitter<mratsim> but it will always quit 1 iirc
15:45:41FromGitter<mratsim> nimble publish never managed to get to an actual PR for me @samdmarshall, though it can create the branch, iirc last time I tried I had to commit and PR manually
15:46:33FromGitter<samdmarshall> @mratsim i
15:47:48FromGitter<mratsim> That I completely gave up on nimble publish :p
15:48:57FromGitter<samdmarshall> oh, my intention is to remake it from the ground up, I guess? so nimble has a defined language in which it can interact with package lists
15:50:22FromGitter<mratsim> the whole nimble or just the publish part?
15:51:37FromGitter<samdmarshall> i guess that really depends on what the answer to this is: https://github.com/nim-lang/nimble/issues/622#issuecomment-478399428
15:52:00FromGitter<samdmarshall> and since this seems like an involved discussion I kinda wanted to have it not via GitHub issues
15:55:23FromGitter<mratsim> Something like argparse as a stdlib module would be awesome. I really like how cligen feels (though extending it with new types was a bit strange last time I tried)
15:56:06FromGitter<samdmarshall> i mean, we have parseopt, and that is exactly what i'm talking about there
15:56:10shashlicksamdmarshall - there's been multiple discussions around how the directory should be maintained
15:56:48FromGitter<samdmarshall> just like with python's argparse, it just requires initializing a sub-parser per command
15:59:29FromGitter<samdmarshall> realistically all i want is to be able to publish my own packages to a package list I personally use -- however it feels wrong and irresponsible to try to implement that without thinking forward about it. this isn't the first package manager i've worked on so i'm somewhat familiar with the risks involved
15:59:46shashlickjust read the issue
16:01:01shashlickthere's a lot going on with nimble and dom96 has been very busy off late - if you want to make progress on the issue, I will definitely recommend not making large changes
16:02:09FromGitter<samdmarshall> yeah, nor do i want to undertake something so large alone
16:02:51FromGitter<samdmarshall> but realistically, the summary of this isn't to add a small piece of functionality to the `publish` command, is it?
16:09:23shashlickam looking at the code
16:09:41shashlickbut first impression is that improving the CLI parsing is a distraction
16:12:03FromGitter<samdmarshall> i know that, but at some point that will need to be improved upon otherwise it is a lot of reliance on global state
16:14:28*enow joined #nim
16:14:30enowHi
16:14:43enowIs it possible to run nim w/o including the system
16:15:00enowand IO libraries
16:15:27shashlickI understand, you will have to convince dom96 on that, but I don't know how important that is with all the other things on the issue list and backlog
16:17:15FromGitter<mratsim> I think we need additional trusted maintainers for nimble
16:18:12FromGitter<mratsim> And even though parsing is a side-issue, i think it's a good enough issue to start hacking on to gradually understand the codebase and relieve the current team
16:21:05shashlickfair mratsim, but with 133 open issues, there's other ways to ramp up - publish is certainly broken so that's great in and of itself
16:25:08*mosORadi joined #nim
16:25:49FromGitter<samdmarshall> a package manager, nevermind language manager is a project for a team of people, not one person -- regardless of size of the community the corresponding language has
16:33:01*ng0 joined #nim
16:33:16shashlickand your contributions will be more than welcome, I am just saying that you will find more success keeping the changes focused, that's just from my personal experience
16:34:23shashlickand i'll let dom96 comment on cli parsing changes
16:34:44shashlicki know I can help with reviewing and accepting bug fixes, not major changes
16:37:46FromGitter<samdmarshall> yeah, i expect as much -- i'm doing my due-diligence to ensure everyone is on the same page.
16:42:36shashlickabsolutely - i do the same before starting code changes
16:46:26*al_t joined #nim
16:46:26*al_t is now known as al_
16:56:56*sealmove joined #nim
17:03:16*nsf quit (Quit: WeeChat 2.4)
17:04:54*nsf joined #nim
17:14:13*rnrwashere joined #nim
17:19:26*uvegbot joined #nim
17:21:18*Jesin quit (Quit: Leaving)
17:23:08*nsf quit (Quit: WeeChat 2.4)
17:24:04*nsf joined #nim
17:37:20*Jesin joined #nim
17:37:53*abm joined #nim
17:48:23*lritter quit (Ping timeout: 245 seconds)
17:52:34*neceve quit (Remote host closed the connection)
18:01:40*natrys joined #nim
18:16:37*rnrwashere quit (Remote host closed the connection)
18:29:40*al_ quit (Quit: al_)
18:30:36*rnrwashere joined #nim
18:34:52*mosORadi quit (Quit: Connection closed for inactivity)
18:49:12*theelous3_ joined #nim
18:56:37shashlicktravis has become useless, just fails and doesn't log errors
19:10:12*I_Right_I joined #nim
19:11:24*Trustable quit (Remote host closed the connection)
19:22:10rayman22201@Araq are you still around? or anybody familiar with the owned ref proposal... Is that SixteNim guy on to something on the 'owned' refs proposal? I think there is a bug in the linked list example you show. I my understanding correct here? https://pastebin.com/raw/EwrHKMMt
19:24:05rayman22201reading the Gel paper, I see the linked list data structure, but I do not see a delete procedure to compare implementations...
19:25:02FromDiscord<has1> What do you guys think about v lang
19:41:18rayman22201I think the only way to make delete work is to have it take ownership of the element and return that owned reference. similar to what the gel paper describes in their "take" operation?
19:51:43*narimiran quit (Ping timeout: 245 seconds)
19:53:29rayman22201@has1 V seems cool, but it's vaporware until it's release. I feel similarly about Jai...
19:53:58*enow quit (Remote host closed the connection)
19:55:57*rnrwashere quit (Remote host closed the connection)
20:21:02*rnrwashere joined #nim
20:21:55*rnrwashere quit (Read error: Connection reset by peer)
20:23:17*rnrwashere joined #nim
20:24:09FromDiscord<exelotl> Jai amazes me because there's like, editor plugins and fan pages and everything
20:24:17FromDiscord<exelotl> for a language that doesn't even exist yet
20:26:12*nsf quit (Quit: WeeChat 2.4)
20:27:19Calinouit's like a waifu, but for programming languages? :P
20:27:32*rnrwashere quit (Ping timeout: 245 seconds)
20:29:12rayman22201lol
20:29:36*rnrwashere joined #nim
20:29:36FromDiscord<exelotl> pffff
20:33:47*rnrwashere quit (Ping timeout: 245 seconds)
20:35:59Araqrayman22201, maybe
20:41:42AraqI think you're right and you need to do proc delete[T](list: var List[T]; elem: var Node[T]) so that elem can be set to 'nil'
20:42:33*bobby quit (Ping timeout: 245 seconds)
20:44:16*Vladar quit (Remote host closed the connection)
20:48:41rayman22201That would work for a doubly linked list, but then the `prev.next` field would transfer ownership to the delete procedure and be set to nil immediately.
20:49:03rayman22201i.e. that would not work for a singly linked list :-P
20:50:10rayman22201*immediately == at that start of the procedure call
20:51:32Araqevery deleteNode operation seems to share this problem, you need to prove that 'elem' is inaccessible afterwards
20:51:43rayman22201does your proposal allow returning owned refs?
20:52:35Araqsure but then you cannot do 'getElemFromList' without removing the owned ref from it
20:52:57rayman22201you are correct, this is a common problem with delete
20:53:35Araqone solution is to introduce a real 'delete' parameter passing mode
20:53:50Araqbut nobody will accept that :P
20:55:12*rnrwashere joined #nim
20:56:08AraqI wonder why it's not covered by the Gel article
20:58:15rayman22201I don't see anything in the source code of Gel either. Which is annoying / suspicious to me :-P
20:58:55rayman22201> 1:52 PM <@Araq> sure but then you cannot do 'getElemFromList' without removing the owned ref from it
20:58:55rayman22201Why not?
20:59:09Araqbecause ownership is unique
20:59:29*rnrwashere quit (Remote host closed the connection)
21:00:11rayman22201It is the onus of the "delete" operation to get an owned reference. This will be unique to each data-structure (worst case is a search).
21:01:31rayman22201for example: https://pastebin.com/raw/TDV973Wk
21:01:33*rnrwashere joined #nim
21:01:33Araqyeah I need to own the elem so that I can remove it but when I'm the owner it's already been removed
21:01:52rayman22201exactly
21:03:38Araqok, so that's why, it works
21:03:42rayman22201put another way, the best you can do is a "remove from datastructure" operation, followed by a true "delete" operation. They cannot really be combined.
21:03:49Araqyou don't have to do 'return ownedElem'
21:04:03*vlad1777d quit (Ping timeout: 250 seconds)
21:04:09Araqthen it's freed at the end of the scope
21:04:34rayman22201It will fail when the free is attempted, because the caller still has an unowned ref.
21:05:21Araqgah
21:05:25rayman22201the ref that was used to call the delete in the first place
21:05:26rayman22201lol
21:06:02Araqok, so 'delete' should be a template :P
21:06:18rayman22201lol
21:06:31rayman22201meta-programming to the rescue :-P
21:06:53*rnrwashere quit (Remote host closed the connection)
21:07:00Araqmaybe there is a better way
21:07:40AraqGel is based on C#, C# has inout parameters so they can do the 'elem: var Node[T]' too
21:08:39Araqinstead of 'return ownedElem' you can then do 'disarm elem', right?
21:09:13*rnrwashere joined #nim
21:10:17*rockcavera joined #nim
21:12:01*rnrwashere quit (Remote host closed the connection)
21:13:46rayman22201I see. So it would be var, but it would still be "un-owned". Yeah. That would work.
21:15:30*Bob- joined #nim
21:17:35*rnrwashere joined #nim
21:19:12*rnrwashere quit (Remote host closed the connection)
21:26:43Araqyou can also disable '=' for Node[T] and use a 'sink' parameter
21:27:08Araqthen you can't use 'elem' after the call to delete
21:27:58Araqbut the unrestrictive use of unowned refs is kinda the point
21:29:59Araqon the other hand... returning what has been unlinked makes sense too, then you can link it into a different list
21:31:12rayman22201All are valid options.
21:32:02Araqstill a bummer. I didn't expect an API change for it
21:32:39rayman22201Sorry ☹️
21:32:55Araqwell linked lists seem to be very special :P
21:33:27Araqboth Rust and Swift struggle with them too :-)
21:35:51*ng0 quit (Quit: Alexa, when is the end of world?)
21:36:56rayman22201Lol. True
21:38:59Araqdelete(list, disarm(elem)) ?
21:42:08rayman22201That won't work because the unlink has to happen before the disarm.
21:42:09*noeontheend joined #nim
21:43:13Araqtemplate disarm(x): untyped = (let tmp = cast[owned typeof(x)](x); x = nil; tmp) # we need an 'owned' without a destructor
21:45:34rayman22201You end up with two owners, "prev.next" still owns x.
21:46:19rayman22201Gel specifically dis-allows casting from un-owned to owned for this reason I think.
21:46:51Araqwell 'cast' is what it is, it's not a conversion it's a "I know better, thanks, get out of my way"
21:47:20Araqwe're still missing something. 'delete' is unlike the others. We have "takes ownership" and also ordinary parameter passing modes etc.
21:47:27shashlickAraq: is it possible to control the order in which passC pragmas take effect?
21:47:38shashlicki have some in an import file which take precedence
21:48:10Araqshashlick, I don't know, maybe passC also supports $1 for prepending/appending but I doubt it
21:48:32rayman22201@Araq, well, isn't that what "sink=" is for?
21:49:07Araq'sink' says "I'm taking over", it's for add-like operations
21:49:30Araqdelete doesn't say "I'm taking over", it says "I'm gonna nuke this one"
21:49:41rayman22201that is a form of taking over :-P
21:50:55Araqit's very different. For example: collection.add(myRef); myRef.data = 2 # bad style, but usually ok
21:51:16Araqin Rust it says "cannot use myRef as it has been moved into collection"
21:52:17Araqthat's overly pessimistic because 'add' and 'delete' are mapped to the same semantics
21:53:57Araqbut *shrug* it is bad style and harmful in a multi-threaded setting
21:55:34rayman22201As you say, it depends on how pessimistic / strict you want to be .
21:55:34*noeontheend quit (Remote host closed the connection)
21:58:53FromGitter<jivank> I am working on a webapp using rosencrantz, I noticed that for serving files asynchronously it will use up to 2gb ram (for a 3gb file) where the system memory is 10gb. I tried limiting the memory usage in docker to 16mb and it seems to work and not crash. Just wondering if there are any parameters for the GC to prioritize low memory usage
22:00:00rayman22201I think the ability to disarm the unowned ref by making it an inout parameter, while not the most obvious or elegant solution, should be sufficient?
22:00:14Araqrayman22201, yeah. for now.
22:00:34*noeontheend joined #nim
22:00:53Araqjivank: I don't know how rosencrantz does the file serving
22:02:46rayman22201I personally prefer the unlink operation that just returns an owned reference. I like obvious semantics that gives me as the caller more control, but I also realize that it is a big API change and not everyone will like those semantics...
22:03:57FromGitter<jivank> https://github.com/andreaferretti/rosencrantz/blob/master/rosencrantz/staticsupport.nim#L33
22:04:10FromGitter<jivank> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5ca28ada3ebbdc55b346352b]
22:05:42Araqrayman22201, I agree
22:05:46FromGitter<jivank> i guess its not a big deal, at the end of the day the application will still work if it has a limited amount of memory.
22:05:55Araqjivank: that doesn't seem too bad
22:06:11Araqwhy does it take up 2GB?
22:08:49*seni joined #nim
22:10:05FromGitter<jivank> i am not sure.. my guess is that the GC reads total memory and allows the application to allocate some percentage? when i set the memory limit to 16mb, the app only uses 5mb of ram.
22:10:58FromGitter<jivank> and it seems to use more cpu with that constraint iirc
22:13:20Araqthe GC doesn't do anything like that
22:14:42*rnrwashere joined #nim
22:14:45FromGitter<jivank> hmm. maybe its something linux specific. i'd have to compare across platforms
22:15:19*rnrwashere quit (Remote host closed the connection)
22:15:25*rnrwashere joined #nim
22:17:06FromGitter<jivank> also maybe what synology is reporting for ram usage is incorrect
22:19:32*stefanos82 quit (Remote host closed the connection)
22:24:40FromGitter<jivank> yes... i think the synology ui was incorrect. i only see 6mb of usage :D
22:24:43FromGitter<jivank> via htop
22:25:27FromGitter<jivank> sorry about that. had a little too much trust in synology..
22:46:02*natrys quit (Quit: natrys)
22:49:02I_Right_Ihows the newruntime coming along?
22:52:12*seni quit (Quit: Leaving)
22:54:48rayman22201Just working out the kinks I would say :-P follow along on the github RFC: https://github.com/nim-lang/RFCs/issues/144
23:03:13*krux02 quit (Remote host closed the connection)
23:11:37*rnrwashere quit (Remote host closed the connection)
23:11:56*rnrwashere joined #nim
23:20:53sealmovewhat does "in-out" mean?
23:30:15rayman22201a parameter that you can write back into. https://en.wikipedia.org/wiki/Parameter_(computer_programming)#Output_parameters
23:31:30rayman22201many modern languages make parameters read only by default. those are "in" parameters. There is also, out parameters, (like Nim's special "result" variable). And in/out lets you do both.
23:31:49*NimBot joined #nim
23:32:03rayman22201coming from C, yes lol
23:32:18sealmovehah i see, ty
23:32:47rayman22201Yeah. It's programming language design terminology. sorry for being confusing...
23:33:02sealmovenp, have to learn the jargon
23:34:11sealmoveoh, and I just realized normal parameters in nim are not necessarily call-by-value
23:34:22sealmoveif you want that you shadow the argument
23:34:57rayman22201It's actually more subtle than call by reference since it works for value types.
23:35:01*Jesin joined #nim
23:36:01sealmovei see
23:39:09sealmovesorry in advance if too naive but if `if elem.prev != nil: elem.prev.next = elem.next` aborts because of elem.prev.next's ref count, why not just set it to nil?
23:39:29sealmove`if elem.prev != nil: elem.prev.next = nil; elem.prev.next = elem.next`
23:39:47*rnrwashere quit (Remote host closed the connection)
23:42:11sealmoveah, that's probably the second option you discussed
23:42:30*rnrwashere joined #nim
23:43:14sealmoveyeah it seems natural, i don't see any problem with elem being an in-out param
23:43:28sealmovesince it has to be disarmed
23:43:31*noeontheend quit (Ping timeout: 250 seconds)
23:46:26sealmove`if elem.prev != nil: elem = nil; elem.prev.next = elem.next` *
23:47:07rayman22201yup. that's the one
23:47:24*rnrwashere quit (Ping timeout: 268 seconds)
23:47:32rayman22201which only works if elem is pass by reference / in-out
23:47:38sealmovebut we need template for temp
23:48:00rayman22201no template needed. That was Araq trying to find a more elegant solution.
23:48:24sealmovebut after `elem = nil` then `elem.prev.next` is invalid?
23:49:06rayman22201you need a temp variable to hold "elem.prev" before you unset it.
23:49:31sealmoveyeah that, ok, doesn't have to be template
23:49:32*rnrwashere joined #nim
23:49:34rayman22201you don't need a template for that, but you do have to create a temp variable.
23:49:54rayman22201yup
23:51:00sealmoveso what do you think overall? it's getting rather philosophical at this point... but I believe fully automated MM is impossible if you want good code
23:51:59rayman22201I really like it. There are a few "ugly" edge cases, like this one, but linked lists are hard in general.
23:52:12rayman22201It feels like "rust lite" in a good way.
23:52:26sealmoveyup exactly!
23:52:31rayman22201then again, I'm very biased. I don't like GC's
23:53:45*rnrwashere quit (Ping timeout: 246 seconds)
23:54:03sealmovewell people ARE coming for GC languages but I think if everyone was a bit more open-minded everything would work fine, because as you said it's 'lite' in a good way, a way that forces you to reason about important properties of your program but doesn't bomb you with having to do weird anotations
23:54:20sealmovei think it's the correct balance
23:54:32sealmoveor at least a very good step towards that
23:55:04rayman22201It's actually more like "swift lite" if I'm being honest. But both swift and rust languages were invented by the same people, so I don't feel so bad lol
23:56:20sealmovei have an idea
23:56:38sealmoveto persuade ppl that it's not so bad
23:56:55sealmovemaybe during the transition period, compiler can throw suggestions?
23:57:16rayman22201That is the plan actually
23:57:23*rnrwashere joined #nim
23:57:38sealmovelike: you use the currect runtime with GC, but compiler still makes suggestions about were to put `owned`. is that even possible/
23:57:40sealmove?*
23:58:06sealmovealso if it is, maybe we can make a semi-porting tool (like python2 -> python3)
23:59:08rayman22201I was going to write a longer post about how plenty of people came from dynamic GC languages to Rust, which is waaaay more unforgiving, and they are very happy. So I don't think it will really put people off as much as the Varriount and andreaferretti think