<< 29-10-2019 >>
00:18:51*clyybber quit (Quit: WeeChat 2.6)
00:20:20FromGitter<juancarlospaco> Hi
00:21:30FromGitter<juancarlospaco> https://github.com/nim-lang/Nim/pull/12549#issuecomment-547200137
00:22:02*Jesin quit (Quit: Leaving)
00:25:39*Jesin joined #nim
00:29:06*EA96 joined #nim
00:31:34*theelous3_ quit (Ping timeout: 268 seconds)
01:13:43*EA96 left #nim (#nim)
01:18:44*sealmove quit (Quit: WeeChat 2.6)
01:27:02FromGitter<gogolxdong> @treeform hash of Color is missing.
01:29:18FromGitter<gogolxdong> and what's the difference between dom2 and stdlib dom?
02:02:55*seni quit (Quit: Leaving)
02:04:50FromGitter<gogolxdong> according to what stdlib hashes have , suggest to define as ⏎ type ⏎ Color* = tuple[r,g,b,a:float32] ⏎ which has similiar semantics with object. [https://gitter.im/nim-lang/Nim?at=5db79e423d669b28a0f4f012]
02:10:17*kevin joined #nim
02:10:40*kevin is now known as Guest51156
02:13:05*Guest51156 quit (Client Quit)
02:13:25*kevin_ joined #nim
02:21:29kevin_hi, I'm new
02:22:19disruptekHI KEVIN
02:28:58kevin_I come from Kotlin :D , just a developer not core-lang design :D
02:29:14disruptekah, cool.
02:30:31kevin_nowaday, alot programming languages based on LLVM, except Nim/Go ... and I'm interesting on Nim
02:31:00kevin_I hope all you guys can grow up Nim as popular language in next time
02:31:12disruptekwell, nim has an llvm backend under development.
02:36:43kevin_I saw Nim compile to C/C++/JS ? it's another compiler isn't it ?
02:37:58disruptekhttps://github.com/arnetheduck/nlvm
02:42:08kevin_look nice ! It's official ?
02:42:31disruptekit's not implemented by the same authors, if that's what you mean.
02:42:40shashlickNo it isn't official
02:44:35FromDiscord<Rika> Heya
02:44:48FromDiscord<Rika> Does nim have a docstyle guideline
02:45:15*Jjp137 quit (Read error: Connection reset by peer)
02:45:49FromDiscord<Rika> Found it
02:48:39*rockcavera quit (Remote host closed the connection)
02:48:42kevin_I hope author keep Nim still simple, programming was more complex don't want any advantage
02:52:24FromDiscord<Rika> Okay, I said found it, but I didn't find what I wanted precisely
02:52:47FromDiscord<Rika> kevin_ nim can be simple or complex, depending on what you make
02:53:18FromDiscord<k1tt3hk4t> I don't think language complexity is a bad thing at all, as long as it's not *arbitrary* complexity, like the level of boilerplate a language like Java has
02:53:59FromDiscord<k1tt3hk4t> I'm glad to use abstractions at the same level that Haskell has if it makes approaching the problem im working on much simpler-- it just requires me to learn how to use them beforehand, and from there on it's an already sunk cost and I know how it works
02:57:04kevin_I mean 'simple' not 'simpler', language can do anything by a simple way :D
04:15:43*sagax quit (Ping timeout: 245 seconds)
04:20:20*fanta1 joined #nim
04:27:57*kungtotte quit (Ping timeout: 240 seconds)
04:35:06*nsf joined #nim
04:41:36*narimiran joined #nim
04:42:57*Jjp137 joined #nim
04:45:04*kungtotte joined #nim
04:47:41*dddddd quit (Remote host closed the connection)
05:01:43*kevin_ quit (Ping timeout: 265 seconds)
05:02:32*chemist69 quit (Ping timeout: 276 seconds)
05:04:14*chemist69 joined #nim
05:15:15*Cthalupa quit (Ping timeout: 265 seconds)
05:43:21*fanta1 quit (Quit: fanta1)
06:08:48*Cthalupa joined #nim
06:13:50*kevin_ joined #nim
06:32:13*solitudesf joined #nim
06:39:06*Cthalupa quit (Ping timeout: 268 seconds)
06:40:58*sagax joined #nim
06:45:48*Trustable joined #nim
06:46:52*kevin_ quit (Quit: Leaving)
06:54:31*Cthalupa joined #nim
07:00:00*gmpreussner_ quit (Quit: kthxbye)
07:04:53*gmpreussner joined #nim
07:06:36*fanta1 joined #nim
07:16:06*Trustable quit (Remote host closed the connection)
07:29:04*PMunch joined #nim
07:39:17*Cthalupa quit (Ping timeout: 240 seconds)
07:44:03*filcuc joined #nim
07:49:54*GordonBGood quit (Remote host closed the connection)
07:53:02*GordonBGood joined #nim
07:54:13*Cthalupa joined #nim
07:55:57PMunchAm I being an idiot here? http://ix.io/2078
07:56:30Araqexportc?
07:56:54PMunchAll the log statements prints the same information, but the caller of the DLL says that the Nim version sets the qstate to module_wait_initial (the 0 value for that enum).
07:57:21PMunchIsn't it supposed to be?
08:00:57Araqunclear question
08:01:29PMunchI mean it appears to work fine, it just doesn't seem to actually change the value of that field in the passed struct
08:03:02PMunchOooh, wait
08:03:15PMunchThe Nim enum is 1 byte, while the C enum is 4
08:03:28PMunchCan I force an enum to be a certain backing type?
08:03:42*gmpreussner_ joined #nim
08:03:48Araqyes
08:04:03PMunchHow?
08:04:06Araqtype T {.size: 4.} = enum
08:04:07Araqiirc
08:04:09PMunchI tried to find it in the manual
08:04:49*gmpreussner quit (Ping timeout: 268 seconds)
08:04:52PMunchThat worked fine
08:05:08PMunchMaybe that should be mentioned here? https://nim-lang.org/docs/manual.html#types-enumeration-types
08:06:02PMunchI mean the only mention I can find of it is this: https://nim-lang.org/docs/manual.html#set-type-bit-fields
08:07:31Araqit should
08:08:53PMunchNever found the docs about creating DLLs with Nim and how the GC behaves in that case by the way
08:09:10*krux02 joined #nim
08:10:11*filcuc quit (Quit: KVIrc 5.0.0 Aria http://www.kvirc.net/)
08:10:31*filcuc joined #nim
08:17:57*Cthalupa quit (Ping timeout: 240 seconds)
08:21:40*Cthalupa joined #nim
08:31:11*Cthalupa quit (Ping timeout: 276 seconds)
08:37:19*theelous3_ joined #nim
08:42:21*Cthalupa joined #nim
08:43:54*kevin joined #nim
08:44:16*kevin is now known as Guest60429
08:52:03*floppydh joined #nim
08:54:12*solitudesf quit (Ping timeout: 265 seconds)
08:56:40*Cthalupa quit (Ping timeout: 252 seconds)
08:58:10*Vladar joined #nim
09:02:41*Cthalupa joined #nim
09:10:51*Cthalupa quit (Ping timeout: 240 seconds)
09:13:32*jjido joined #nim
09:19:05*ng0 joined #nim
09:21:53*kevin_ joined #nim
09:22:52*kevin_ quit (Client Quit)
09:29:39*Cthalupa joined #nim
09:36:11*Cthalupa quit (Ping timeout: 250 seconds)
09:39:54PMunchHmm, how do I declare that a field in an object is a pointer to a function in C?
09:40:54FromDiscord<mratsim> @Araq, @GordonBGood, what's this with non-functionning shallow? Would that break this? https://github.com/mratsim/Arraymancer/blob/a555fae806c5f795d4f664ca1eefd945d413933b/src/tensor/data_structure.nim#L21-L30
09:41:46Araqdepends on what you need the .shallow for
09:41:58FromDiscord<mratsim> for reference semantics of sequences
09:42:25Araquse a refseq[T] instead inside your object
09:43:18FromDiscord<mratsim> no way around the double indirection?
09:43:58Araqthere is no double indirection, it would be dedicated container that has a refcount inside
09:44:08FromDiscord<mratsim> ah nice
09:44:41FromDiscord<mratsim> well it's not critical as the ref seq would only be used for sequences of strings in the future
09:44:42Araqbut I don't want to add an RC to the standard 'seq' because most usages don't need it
09:44:44FromDiscord<mratsim> see https://github.com/numforge/laser/blob/master/laser/tensor/datatypes.nim#L24-L30
09:45:27Araqwhat we are really doing here is to give you the tools to write your own seq that works as well as the current builtin one, arguably it works better
09:45:44Araqand that's why allocators.nim is a wrong design
09:46:29Araqas it does a bunch of runtime dispatches, it's easy to fall into the trap of "one container type that can do everything"
09:46:32FromDiscord<mratsim> my main issue with the current seq is the allocator 😛
09:47:05Araqthat's one way of looking at it but IMO the question is "why can't I write my own seq"
09:48:23FromDiscord<mratsim> Basically the reasons why I want to use raw pointers in the future:
09:48:24FromDiscord<mratsim> - being able to have zero-copy of NumPy buffers for python interop
09:48:24FromDiscord<mratsim> - I need a caching allocator. Nothing fancy but a deep learning training loop creates and destroy tensors a lot
09:49:18Araqas I said, if you write the seq you are free to choose the allocator anyway
09:49:50*solitudesf joined #nim
09:51:02FromDiscord<mratsim> yeah that's good for me
09:51:02AraqI'm looking forward to seqs that use an int32 or smaller for length and capacity
09:51:48FromDiscord<mratsim> for Picasso, I think I used that.
09:52:10*Cthalupa joined #nim
09:52:29FromDiscord<mratsim> I don't think anyone has 2 billions threads on their machine.
09:52:40Araqyup
09:57:11FromGitter<alehander42> one thing i dont like
09:57:21FromGitter<alehander42> is that this means one cant use custom code with his own allocator
09:57:51*Cthalupa quit (Ping timeout: 250 seconds)
09:58:00FromGitter<alehander42> e.g. can i just import a lib and run some calls in my bare metal thing telling it "just use my dummy allocator" ?
10:00:38AraqI dunno why you would want that, nor how it could work, if the library used cudaMalloc maybe it had its reasons
10:01:43Araqwell you can patch the malloc in C fwiw
10:01:46FromGitter<alehander42> yeah, but most normal code doesnt really care honestly
10:02:00Araqand libraries should obey to -d:useMalloc
10:02:13FromGitter<alehander42> i mostly want to be able to somehow override the whole allocation mechanism
10:02:18FromGitter<alehander42> i dont care how a lot
10:02:34FromDiscord<mratsim> if allocation pattern i very important, the library author should provide compile-time switch
10:02:57FromDiscord<mratsim> many C lib offer a USE_JEMALLOC switch for example
10:02:59FromGitter<alehander42> ok, but e.g. on bare metal, or hobby osdev i dont even have C or malloc
10:03:21*jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
10:03:24FromGitter<alehander42> i just want to tell nim "all of your alloc / free calls => just redirect them to my memory manager stub"
10:03:24Araqyeah and mmdisp has a mechansim to turn a globally declared buffer into a heap
10:03:25FromGitter<alehander42> or something
10:04:00Araqvar heapEmulation: array[N, byte]
10:04:16FromGitter<alehander42> so i guess, using -d:useMalloc and overriding malloc/free should be the way in those cases
10:04:19Araqproc alloc(size: int): pointer = addr heapEmulation[heapPtr]
10:04:22FromDiscord<mratsim> I think however that this has value if we just want to add alloc statistics or debugging info
10:04:55FromGitter<alehander42> but can i override this in user code ?
10:05:02FromGitter<alehander42> or do i need to patch my compiler
10:05:29FromGitter<alehander42> i remember i tried to do something like that but it still didnt quite do it
10:05:35FromGitter<alehander42> but ill try again when i can
10:07:07Araqthat's the usual programming mysticism
10:07:34Araqso you don't have the memory for a heap and yet you want to override code that used malloc
10:08:06FromGitter<alehander42> i do have the memory for a heap
10:08:12FromGitter<alehander42> i can just define my own malloc
10:08:24FromGitter<alehander42> i just assumed it would be easier to override stuff directly from nim
10:09:02Araqit's quite easy, but you need to get dirty and look at lib/system/mmdisp.nim
10:09:26Araqbecause I don't want to expose all this via global function pointers
10:10:50Araqthey kill some optimizations and you need quite a few of these, alloc/allocShared/isAllocatedPtr (for the old GCs)/getTotalMem/etc etc
10:11:54FromGitter<alehander42> yes, i just imagine being able to somehow tell "use this userland module/override" even with a compiler switch, without runtime indirection
10:11:59FromGitter<alehander42> but not sure how would it work
10:12:25FromGitter<alehander42> and overally, just patching c_malloc def/mmdisp isnt a big deal of course
10:13:22FromGitter<alehander42> if it's enough to just run simple nim code with gc directly
10:14:00Araqin reality there is no alternative over compiler/linker switches
10:14:11Araqyou cannot do kernel development in C without these either
10:14:31Araqbut I agree we can make overriding the memory subsystem easier to do via the command line
10:15:53FromGitter<alehander42> i agree, overriding on ct is still useful, and even for other subsystems (e.g. profiling hooks etc)
10:19:48*clyybber joined #nim
10:20:04FromGitter<alehander42> https://forum.nim-lang.org/t/5421
10:21:11FromGitter<alehander42> cool to review
10:23:28clyybberinteresting
10:23:39clyybberbtw alehander42: Your breeze macro is very cool
10:23:56*tklohna_ quit (Ping timeout: 252 seconds)
10:23:56clyybberWe should include in the stdlib IMO
10:24:02clyybberor something akin to it
10:24:31FromGitter<alehander42> yeah, it just immitates karax, i agree it seems useful
10:24:52FromGitter<alehander42> but i have to admit i dont really use it, too lazy to install / import it
10:25:31clyybberheh
10:26:04Araqoh really?
10:26:23Araqhttps://github.com/nim-lang/RFCs/issues/173
10:26:33FromGitter<alehander42> but maybe a simpler thing like https://github.com/nim-lang/Nim/pull/7508#issuecomment-434027201
10:26:34Araqmeans I'm onto something here :P
10:26:45FromGitter<alehander42> i knew that you would count it
10:26:48FromGitter<alehander42> as an argument :P
10:27:02Araqit was an argument in its favor
10:27:23Araqdon't you agree?
10:27:30FromGitter<alehander42> well, i often use some other libs, like chronicles, args parsing stuff, etc
10:27:46FromGitter<alehander42> so i'd say that its more like , trying to use less dependencies if i can
10:28:25FromGitter<alehander42> if a library is really worth saving me work, its no problem to add it
10:28:27*Cthalupa joined #nim
10:28:33clyybberAraq: I generally agree, but in this case it would be cooler to have it baked in the stdlib because it's just so much more handy and everyone should profit.
10:29:43clyybberAraq: Btw do you have an idea what could cause 'Error: cannot eval at compile time' for code that I transformed/generated in transf.nim?
10:30:05clyybberIt works when I compile the code manually.
10:30:08Araqnot really but the VM also uses transf.nim, beware
10:30:39Araqclyybber, ok, so how do we add it the stdlib? just do it and live with the fallout?
10:30:54clyybberAraq: Yeah? What fallout?
10:31:02Araqput under std/experimental so we garantee to break it eventually?
10:31:22Araqput it under std/ because it *might* become a stdlib?
10:31:45clyybberYeah
10:31:55Araqthe idea is that the stdlib adopts battle-tested code
10:32:01FromGitter<alehander42> it's quite possible to change api i agree
10:32:08FromGitter<alehander42> that it needs to be played with more
10:32:22AraqC++ does it via Boost, first it's in Boost, later on in the stdlib
10:32:52FromGitter<alehander42> but i think more that
10:33:08FromGitter<alehander42> a better solution usually is just to make "very useful" libs
10:33:20FromGitter<alehander42> e.g. i wouldnt always install breeze
10:33:30Araqthat works for some code, yes, but not for others
10:33:33FromGitter<alehander42> just for 1-2 cleaner things
10:33:43Araqfor example, I would love to use your for-loop-expression stuff
10:33:46FromGitter<alehander42> but i would install very often a more general "macro niceties" lib
10:33:53Araqbut I don't want to depend on it
10:34:11FromGitter<alehander42> well, you cant use something without depending on it
10:35:14Araqbut the dependency is exposed, I can write Karax example code that uses for loop expressions, and then karax depends on your package, but
10:35:26Araqa) it doesn't *really* depend on your package, only some example code
10:35:27Araqand
10:35:58Araqb) if everybody would take this stance we get bloat and slow 'nimble install x' commands
10:36:07FromGitter<alehander42> actually i remember https://github.com/alehander42/comprehension/pull/1/files seemed as a better impl, i just copied the idea of some araq macro and prototyped that
10:36:22Araqnot too mention that the chance of Nimble failing due to networking errors increases etc etc
10:36:35FromGitter<alehander42> yeah, but thats kinda my point
10:36:53FromGitter<alehander42> it's more worth it, if those things are in bigger libs
10:36:56FromGitter<alehander42> which have more usages
10:37:18*Cthalupa quit (Quit: ZNC 1.6.6+deb1ubuntu0.2 - http://znc.in)
10:37:23clyybberHmm, I don't agree
10:37:33FromGitter<alehander42> e.g. comprehension could be in something like "functional" or extra_sugar lib
10:37:38clyybberI much rather pull in simple small libs that do one thing and do it right
10:37:41FromGitter<alehander42> or breeze could be in macroutils
10:37:42FromGitter<alehander42> libs
10:37:56FromGitter<alehander42> interesting, so thats subjective
10:38:16Araqit's not really, count how often 'sequtils' is used in the wild
10:38:25FromGitter<alehander42> a lot?
10:38:33Araqmove it into its own Nimble package and see how it's used then.
10:38:38Araq*how often
10:39:00FromGitter<alehander42> well, if a thing like sequtils was totally missing from the stdlib, it would be a pretty popular package
10:39:11Araqbut the effect is real, people avoid dependencies.
10:39:28FromGitter<alehander42> look at stuff like parsing arguments, testing libs , logging libs, benchmarking libs
10:39:28AraqI do, you just admitted that you do it.
10:39:36FromGitter<alehander42> people install them
10:40:10FromGitter<alehander42> but i dont avoid dependencies: i love adding them, i avoid minimal dependencies which i can do without
10:40:25clyybberWell its the opposite for me. I don't like dependencies
10:40:31FromGitter<alehander42> which is very subjective as we saw:clybber is the opposite
10:43:42clyybberBut a dependency small enough that I can just copy the file into my project is nice
10:43:42clyybberI also don't like that nimble just installs the packages into .nimble
10:43:43FromGitter<alehander42> i just dont think this is true at all: look at all ecosystems, go, java, rust, c#: package managers and dependencies are all the rage
10:43:43clyybberInstead of where I use them as dependencies
10:43:43FromGitter<alehander42> but people just try to install those that are worth it imo
10:43:43*Cthalupa joined #nim
10:43:43FromGitter<alehander42> as a pushback to the npm thing
10:43:43clyybberYeah and worth it is IMO
10:43:43*filcuc quit (Excess Flood)
10:43:43clyybbersmall library that I can myself understand and because of its small size is unlikely to break or have to be updated
10:43:44*filcuc joined #nim
10:43:44FromGitter<alehander42> even in c++ people are really experimenting with improving package management somehow
10:43:44Araqyou are happy with dependencies and yet your actions contribute to the effect anyway, people avoid deps.
10:43:44AraqI think it's hard to argue against it. but you can argue that we don't have to do anything about it.
10:44:09FromGitter<alehander42> but from what i see, people in all language communities like reasonable dependencies
10:44:23FromGitter<alehander42> 3rd party libs are thriving even in c++
10:45:32FromGitter<alehander42> i think the python science distributions are the only good example
10:45:45FromGitter<alehander42> of lang specific distros i remember right now
10:46:03FromGitter<alehander42> so its good to have this mechanism, but i'd guess needs just vary a lot
10:46:17FromGitter<alehander42> e.g. even in web, you can imagine 5 teams using 5 different combos of
10:46:24clyybberalehander42: Why would I import some big lib only to use one macro from it?
10:46:37FromGitter<alehander42> template engine + orm + rest api lib
10:47:33FromGitter<alehander42> clyybber, you maybe wont, but if you have small lib a, small lib b and small lib c, imo i'd install abc which just does it all instead of
10:47:44clyybberBut why?
10:47:44FromGitter<alehander42> installing only a for only one thing
10:48:03FromGitter<alehander42> because abc would do more stuff for me
10:48:24FromGitter<alehander42> in the same way, i'd use sequtils, not seqmaputils + seqfilterutils + seqcount
10:48:33*Guest60429 quit (Quit: Leaving)
10:49:02clyybberDoing more stuff as in: Requiring more maintenance, updates and in general being harder to understand
10:49:06FromGitter<alehander42> e.g. for stuff like breeze, i imagine if a macroutils has 4-5 similarly useful things
10:49:26FromGitter<alehander42> a lot more people would have at least 1-2 which are useful, so it would have more interest, more maintenance, more bugfixes
10:49:37FromGitter<alehander42> and overally it would move better
10:49:43clyybberHmm
10:49:55clyybberI don't think so, but we are both speculating here L)
10:50:11FromGitter<alehander42> its a bit like npm: left pad is just too specific
10:50:18FromGitter<alehander42> but if it was a stringutils_plus
10:50:31FromGitter<alehander42> a lot more people would be like "ah this makes sense"
10:50:36clyybberI think the linux ecosystem perfectly shows that things that are small and simple are just more reliable
10:50:39FromGitter<alehander42> but i agree this is subjetive
10:50:54FromGitter<alehander42> oh dont use this argument in front of araq
10:51:03FromGitter<alehander42> this example*
10:51:08Araqlook I don't really care how we do it, but in the end a process for PRs against the stdlib is a nice thing
10:51:18clyybberI agree
10:51:57FromGitter<alehander42> i think a distribution mechanism is useful, but maintaining the actual distros should be left to people who are interested
10:52:06FromGitter<alehander42> now if araq just likes to do it, nothing wrong with that
10:52:22WilhelmVonWeinerthere's no null equivalent in Nim is there
10:52:24FromGitter<alehander42> otherwise, pr-ing against the stdlib can just be done with rfc-s
10:52:27clyybberalehander42: See the suckless tools for example
10:52:33Araqbut I don't care about distribution*s*
10:52:45FromGitter<alehander42> but then rfc-s are enough
10:52:45AraqI only want a single one
10:53:01AraqI fear multiple distributions
10:53:02FromGitter<alehander42> but give an example
10:53:05FromGitter<alehander42> what would it include
10:53:25Araqcligen, comprehensions, nim-regex
10:53:42FromGitter<alehander42> because for most things you have 2-3 choices, so e.g. i want to use the distro, but i like 8/10 packages from it and dislike 2
10:54:08federico3what a weird conversation
10:54:27FromGitter<alehander42> ok, cligen has nim-argparse / confutils
10:54:33FromGitter<alehander42> as alternatives
10:54:40Araqmaybe 'nimly' but I haven't reviewed it
10:55:08FromGitter<alehander42> nimly seems cool, but npeg is also developing ok
10:55:19federico3alehander42, clyybber: the problem is not simply about number and size of build and runtime dependencies, rather the tradeoff between risks (vulns, other bugs, libs being abandoned) and the benefits
10:55:31FromGitter<alehander42> i just find it hard to make those decisions
10:56:18FromGitter<alehander42> federico3 well, this is again subjective: a bigger lib might be less likely to be abandoned, but a bigger risk because of its importance
10:56:54clyybberfrederico3: Exactly. And a simple dependency that fits in one file and is easy to understand is just better in those regards than a big package that I have to update regularily for these things.
10:57:00clyybberIMO
10:57:12FromGitter<alehander42> but i dont understand the need of distribution: if a lib is popular, even if it gets abandoned, people can step in, fork and continue
10:57:16federico3alehander42: it depends on where it comes from - is it one developer only or many? Does it has a track record of being maintained or just few months?
10:57:45FromGitter<alehander42> ok, so one can use some kind of metrics index or stats
10:57:56clyybberfrederico3: Look at this for example: https://github.com/Earnestly/sx/blob/master/sx
10:58:04federico3you don't measure the reliability of some hardware by simply weighting it
10:58:10clyybberthis doesn't need much mainetnance because its simple
10:58:20clyybberAs opposed to startx + xinit
10:58:34FromGitter<alehander42> i agree, but a better measurement is then its popularity and reviews/issues
10:58:34clyybberWhich it replaces
10:58:42FromGitter<alehander42> you take a look at the people that already use it
10:58:46FromGitter<alehander42> and make your mind
11:00:01clyybberalehander42: Also look at it that way, simple small self contained packages are unlikely to add many dependencies themselves, avoiding dependency hell.
11:00:13clyybberBut it depends on the people who write them of course.
11:00:19FromGitter<alehander42> but they are just not that useful
11:00:22FromGitter<alehander42> because they're small
11:00:22federico3clyybber: obviously avoiding bloat is always a good thing but there's more to that
11:00:34FromGitter<alehander42> after all, i use dependencies to do complicated stuff instead of me
11:00:44clyybberalehander42: Breeze looks immensily useful, and its small
11:01:04FromGitter<alehander42> ok, but you cant write a fast parser generator in 50 lines
11:01:24FromGitter<alehander42> or a flexible web framework
11:01:38FromGitter<alehander42> or a physics engine etc
11:01:39clyybberalehander42: Fair enough, but I also wouldn't want to import a parser generator that does more than being a parser generator
11:01:56*jjido joined #nim
11:01:57clyybberalehander42: Similarily I want a physics engine to be a physics engine and no more.
11:02:02FromGitter<alehander42> yeah, there is a limit i agree
11:02:07FromGitter<alehander42> my point was not to overdo it
11:02:14FromGitter<alehander42> maybe the best thing is to have both
11:02:17federico3clyybber: I wish it was so simple. They are called "libraries" because we often want a large set of tools in one package
11:02:26FromGitter<alehander42> little packages which do minimal things, and toolkits
11:02:31FromGitter<alehander42> which combine them
11:02:32clyybberThen I want books :)
11:03:02clyybberA physics engine is obviously one really large book, since all parts collide, interact with each other
11:03:08federico3clyybber: careful: that creates the npm disaster
11:03:42clyybberfrederico3: I trust in nimble to be cumbersome enough to use that this wont happen :p
11:03:56federico3one thing that many ecosystem keep forgetting are optional dependencies
11:03:59clyybberNo but really, NPM is the thing I am most afraid of.
11:04:34FromGitter<alehander42> i just think we'll have two trees of libs: ones which are more modular combining small ones
11:04:36clyybberBut I think nim targets a different audience and thus we will hopefully not end up with such bs
11:04:38FromGitter<alehander42> and one which are monolithic
11:04:40federico3clyybber: it's already happening. We have some tiny packages and nimble is still not giving warnings when publishing them
11:04:47FromGitter<alehander42> its just a different approach to stuff
11:05:09FromGitter<alehander42> federico3 but sometimes you really can do something useful in 20 line package
11:05:10clyybberfrederico3: Care to give examples?
11:05:18FromGitter<alehander42> its impossible to automatically
11:05:19federico3alehander42: optional dependencies gives you the best of both worlds
11:05:21FromGitter<alehander42> catch those
11:05:39FromGitter<alehander42> but for optional deps, you need an alternative
11:05:52federico3alehander42: sure - and that why people put the 20 SLOC in a *library* :)
11:06:24FromGitter<alehander42> well, if they really can reuse them in 5 other projects
11:06:25FromGitter<alehander42> why not
11:06:34federico3alehander42: huh? alternative?
11:06:58FromGitter<alehander42> well, i decide not to install my_optional_dep
11:07:02FromGitter<alehander42> how does the code work
11:07:11FromGitter<alehander42> i just dont understand this mechanism
11:07:16clyybberYeah optional dependencies aren't the solution IMO
11:07:21clyybberIf I understand that right
11:07:31federico3they are a very good solution
11:07:33FromGitter<alehander42> i imagine i need to have another dependency which has the same api
11:08:16AraqI don't understand "optional dependencies", it's like "my wife is a little bit pregnant"
11:08:18federico3what you want to avoid is having to pull a large tree of deps where many of the leaf nodes are not useful to you and only cost you (in terms of risk and bloat)
11:08:46FromGitter<alehander42> i agree with araq, i just dont get how they work
11:09:06federico3now, your application A might depend on B that depend on C that depends on D,E,F,H
11:09:10FromGitter<alehander42> tree shaking?
11:09:28FromGitter<alehander42> ok
11:09:42federico3the developer of C can set, for example, E, and H as optional, based on feature that might be needed or not
11:09:48clyybberalehander42: Actually I might have to refine my point a bit. I don't have a problem with a package like macroutils or something that includes breeze. But I would want breeze to be easily importable without importing all the other stuff I wont use. So breeze should be in its own single file.
11:09:51federico3(for example my httpauth package)
11:09:57*vsantana joined #nim
11:10:37FromGitter<alehander42> but how does nimble knows if i would use this feature, like where do i make the decision to include them or not
11:10:45clyybberalehander42: Though then again one could just create a meta-package macroutils which includes breeze and other stuff.
11:10:52federico3and by default E, F, H are not installed. They are controlled with a define, or even better, by a proper mechanism in Nimble that is not implemented yet
11:10:58clyybberAnd breeze would be its own pkg on nimble too.
11:11:38clyybberalehander42: Seems like the solution to all of this is to leverage the hierarchical tree structure of filesystems a bit more.
11:11:43FromGitter<alehander42> clyybber, but thats why a single package would be better: the maintainer still does less work, as he needs to just maitnain one repo, not several
11:11:54FromGitter<alehander42> and you can still import just one of the files
11:11:56federico3having to mock out or replace dependencies is a common problem in distributions
11:12:21FromGitter<alehander42> federico3 makes sense, but this requires good lib author discipline
11:12:41clyybberalehander42: Hmm, but how is maintaining a single repo easier than multiple?
11:12:47FromGitter<alehander42> its one
11:12:50FromGitter<alehander42> not 5 + 1
11:12:50clyybberI actually find its the opposite.
11:12:53federico3alehander42: that's why some languages introduced optional dependencies in the packaging tools
11:13:02clyybberI commit a change to breeze and push it. Boom done.
11:13:13FromGitter<alehander42> well, otherwise i need to bump versions, do releases , fix nimble dependencies
11:13:26FromGitter<alehander42> yeah, but imagine bumping macroutils every time
11:13:30federico3alehander42: and nothing could prevent Nimble from encouraging optional deps
11:13:34FromGitter<alehander42> i change any of the small libs
11:13:37Araqhttps://youtu.be/sBP17HQAQjk?t=1078 argues convingingly IMHO that optional deps are a bad idea
11:13:54clyybberoptional dependencies are not good IMO
11:14:54clyybberIn a slightly different context: Optional dependencies in linux pkg managers are also kinda annoying since they stick around forever.
11:15:37federico3Araq: thanks I'll watch the video later
11:15:45clyybberalehander42: Yeah and I have to get the whole monorepo in a functional state before releasing
11:16:09clyybberWith multiple repos I can just update the different parts seperately
11:16:11federico3clyybber: they are usually inevitable
11:16:34clyybberfederico3: Look at xbps
11:16:41clyybberIt avoids them entirely
11:16:49clyybberAnd its just so much better than lets say pacman
11:17:23clyybberI install pkg A. It pulls in some dependencies. I uninstall it. It removes all dependencies.
11:17:28federico3it has virtual packages in the list of features
11:17:32*abm joined #nim
11:17:39clyybberfederico3: Yeah?
11:17:48clyybberBut those arent optional dependencies..
11:18:00FromGitter<alehander42> interesting talk
11:18:07federico3it's quite similar
11:18:17clyybberfederico3: No, its really not.
11:18:21federico3(besides, pacman is not a good example)
11:18:32FromGitter<alehander42> so his point seems to be if its needed, just release a library C_ which uses the optional E + H
11:18:39FromGitter<alehander42> and depends on your C
11:18:41FromGitter<alehander42> which doesnt
11:18:51federico3clyybber: "similar", not identical
11:19:05clyybberfederico3: Not even similar.
11:19:47federico3it allows switching between alternatives that provide the required features
11:20:00clyybberHmm
11:20:05FromDiscord<mratsim> I want to have my libraries optionally depend on quicktest for property-based testing, cuda stuff for GPU programming, a fuzzer for fuzzing. What do I do?
11:20:18federico3which is often used to migrate away from a dependency that has problems (e.g. bloat, vulnerable, abandoned)
11:20:30clyybberfederico3: Ah, so thats the kind of optional dependencies you are talking about..
11:21:03clyybberfederico3: I was talking about optional dependencies with those options: They are installed.\ THey are not.
11:21:14AraqI suspect we're talking about separate things
11:21:15federico3clyybber: that is one way of loosesing the dependencies
11:21:19FromGitter<alehander42> mratsim this reminds me, i wanted to stop quicktest from depending always on unittest
11:21:35clyybberfederico3: IMO that only works here, because they adhere to standards
11:21:44FromGitter<alehander42> and make it depend on whatever implements the same api
11:21:50clyybberLike I can swap out my driver, but it still implements opengl
11:21:56federico3clyybber: that's another way. The end goal is not to have a unweildy tree of dependencies
11:22:11FromDiscord<mratsim> @alehander42, I don't mind. I fear unittest putting everything in the global space creates stack overflow issue
11:22:32federico3clyybber: in the case of the swap, yes it still implements opengl but perhaps the replacement is leaner, or better mantained, or more secure and so on
11:22:40FromGitter<alehander42> i actually wrote my own mini async unittest which just uses procs, so almost no global space stuff
11:22:46FromDiscord<mratsim> quicktest should probably autowrap everything in procs so that tests are not using global stack variables
11:22:52FromGitter<alehander42> like, it generates procs from `test`
11:22:54FromDiscord<mratsim> which is an issue with seq for example
11:23:11FromGitter<alehander42> but not sure if this breaks many unittest workflows
11:23:28federico3clyybber: and perhaps if you had optional dependencies that you can drop with a flag you could have removed an unneded feature more easily that having to introduce an alternative
11:23:41clyybberfederico3: Yeah, I am not opposed to your idea anymore. Its just that I initially thought you were referring to another kind of optional dependenies
11:23:49FromGitter<alehander42> quicktest still depends on having `check`, and i am not sure `check` would work in a proc
11:24:14FromDiscord<mratsim> check is a really basic templates though
11:24:18FromGitter<alehander42> basically, one has to either fix unittest, or use quicktest with custom unittestlike-lib (which is what i do)
11:24:22clyybberfederico3: But optional dependencies are definitely much more complex and don't solve the same problems as just in general having more KISS kind of packages.
11:24:28FromGitter<alehander42> or make quicktest easy to use with a custom api
11:24:39federico3clyybber: there are many forms of flexibility in the compile time and runtime dependencies.
11:24:41FromGitter<alehander42> mratsim it is easy to replicate in basic sense
11:24:55FromGitter<alehander42> but not so easy to do in its original idea
11:25:12clyybberalehander42: One example is laser, its a bunch of things, but I don't mind since they are seperated in a sane way.
11:25:18FromGitter<alehander42> it should be able to show you intermediate values of subexpressions in check
11:25:36FromDiscord<mratsim> well, we are considering moving away from unittest: https://github.com/stefantalpalaru/nim-unittest2
11:25:52FromGitter<alehander42> which should be improved: overally fixing stdlib unittest should be ok
11:25:59FromGitter<alehander42> hm parallel run, awesome
11:26:06FromGitter<alehander42> we argued with araq several days ago
11:26:14FromGitter<alehander42> as he likes testamenet parallelisms
11:26:31FromDiscord<mratsim> well, the gain from parallelism in our use case was actually minimal somehow
11:26:31FromGitter<alehander42> how do you plan to do parallell runs in unittest2 ?
11:26:42clyybberTheres a PR up
11:26:46clyybberOr there was
11:27:24*Cthalupa quit (Ping timeout: 246 seconds)
11:27:36FromGitter<alehander42> mratsim but is your test cpu bound
11:27:48FromGitter<alehander42> i suspect multithreading helps mostly for io-bound tests
11:28:01FromGitter<alehander42> oh wait, multicore machines
11:28:23FromGitter<alehander42> still, threads always run on the same cpu right
11:28:40FromDiscord<mratsim> well, in our case we were running into Travis timeout
11:28:40FromGitter<alehander42> so i wondered if there is a way to directly map tests on all cores
11:29:21FromGitter<alehander42> if you think about it, usually libs have many test files, maybe just running them on each core in the same time would be easier
11:29:24FromDiscord<mratsim> and Travis machines only have 2 or 3x cores iirc, but the time consuming parts might have been alone in a file and so not parallelized
11:29:50FromDiscord<mratsim> so yes we might need to do the testament way, one file per test, easier to parallelize
11:30:01*Cthalupa joined #nim
11:30:14FromGitter<alehander42> well, you can have a "small" amount per file
11:30:29FromGitter<alehander42> keep in mind the compile time gets much slower sometimes
11:30:34FromGitter<alehander42> for 5x tests
11:30:46FromDiscord<mratsim> or maybe we can have a pragma and on compilation, a table collects all of those and create a pool of task to run
11:30:48FromGitter<alehander42> but i dont understand why multithreading would make a cpu bound test faster
11:31:05FromGitter<alehander42> yeah, something like the last one seems fun and imo fastest
11:31:10FromDiscord<mratsim> because you run multiple CPU bounds test on different cores
11:31:10federico3alehander42: huh?
11:31:11FromGitter<alehander42> as you can still compile just once
11:31:20FromGitter<alehander42> and get parallelism
11:31:22federico3unless you have only one core
11:31:37FromGitter<alehander42> yeah, well, i am just not good at multithreading , trying to learn
11:31:57FromDiscord<mratsim> it's IO tests that won't get faster with multicore, because you might saturate your memory or disk bandwidth
11:32:05*lritter joined #nim
11:32:16FromGitter<alehander42> so i assumed a process runs its threads on the same core
11:32:22FromGitter<alehander42> thats not true?
11:32:26federico3not at all
11:32:34federico3perhaps you are thinking about the GIL in python :)
11:34:12FromDiscord<mratsim> that's true for coroutines/green threads/fibers/async but that is concurrency.
11:34:27FromDiscord<mratsim> Multithreading is about distributing thread on multiple cores
11:34:42*sealmove joined #nim
11:34:52FromGitter<alehander42> ah embarrasing, i got confused because of the shared memory
11:34:58sealmovehi, is there a way to tell the compile to not print errors at stdout/stderr?
11:35:05FromGitter<alehander42> but i forgot all cores share the same memory
11:35:26FromGitter<alehander42> like, you dont have 8 RAM blocks
11:35:29FromGitter<alehander42> oh well
11:36:11FromGitter<alehander42> so yeah, in this case multithreading unittest must be cool
11:36:40federico3alehander42: sharing memory is a different topic (e.g. multithreading on numa)
11:37:16FromGitter<alehander42> yeah, i meant i really imagined each cpu has its own memory, so when you move a thread you have to copy it
11:37:18federico3I ended up spawning threads or processes from unittest often
11:37:26FromGitter<alehander42> but if i think about it, obviously you have one memory
11:37:40FromGitter<alehander42> i really got this confused
11:37:58federico3but you have independent caches and locking mechanisms to sync them...
11:38:08FromGitter<alehander42> well, yeah
11:38:17FromGitter<alehander42> i guess there is a limit
11:38:27FromGitter<alehander42> for small/fast suites, it is not worth it to parallelize
11:38:36FromGitter<alehander42> so one should just benchmarks his own tests
11:38:54FromGitter<alehander42> and have a `--parallel` flag
11:39:38*jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
11:39:49federico3tools like pytest's xdist are clever enough to decide what to do
11:42:29federico3but Nim's effect system could be even used to track test relations and "cache" successful unit tests
11:48:47*vsantana quit (Remote host closed the connection)
11:49:00*rockcavera joined #nim
11:52:38*nc-x joined #nim
11:53:51nc-xlooks like haxe is planning to implement the z3 idea as well https://github.com/HaxeFoundation/haxe/issues/8905
11:54:25*drewr quit (Ping timeout: 250 seconds)
12:04:14*seni joined #nim
12:04:55*nc-x quit (Ping timeout: 260 seconds)
12:05:56clyybberAraq: This is the difference: The left side fails to evaluate in the VM, the right doesn't.
12:08:08clyybberIt's not obvious to me what causes this difference..
12:08:16*tklohna_ joined #nim
12:09:14federico3nc-x[m]: very nice
12:14:27clyybbernc-x[m]: Btw: https://github.com/RapidFingers/Craxe
12:15:15Araqsealmove, --verbosity:0 maybe
12:24:59*sealmove quit (Quit: WeeChat 2.6)
12:40:53*jjido joined #nim
12:48:43clyybberAraq: I'm all for a template that allows us to use inplace operations as non-destructive procs.
12:49:03clyybberI would love to have it in a dot-operator
12:49:55clyybber.~ or .> or .& or some other variant
12:50:22clyybberalehander42: Wdyt fits/looks best?
12:52:13clyybberor .*
12:53:17*Hideki_ joined #nim
12:53:47FromDiscord<mratsim> I already use the dot .* notation in Arraymancer
12:54:05FromDiscord<mratsim> however I don't know the context
12:54:59clyybbermratsim: Its about using inplace procs like `shuffle(var seq)` like so `echo someseq.~shuffle
13:02:04narimiran@mratsim yes you do, you incompetent idiot!! :D :D
13:03:13narimiran(people who don't read forum frequently won't get that reference)
13:03:39clyybber(i don't know that reference, and won't sleep tonight)
13:03:44clyybber(thanks narimiran)
13:03:50narimiranclyybber: :D
13:04:16narimirancongrats, you just received the meta-referencing badge
13:05:24FromDiscord<mratsim> lua uses ":" for chaining that
13:06:31FromDiscord<mratsim> yeah tough luck, I didn't get .* precedence right so I'm incompetent.
13:16:19federico3Araq: saw the video: the speaker recommends not making many different builds but rather "provide optional features as separate libraries with separate builds" with really sounds like optional runtime dependencies
13:20:30*jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
13:25:34Araqfederico3, I suspected it's a matter of definitions
13:26:41Araq*. has *'s precedence, it's a pretty simple system
13:27:31federico3optional [build|runtime] dependency: a library that is not always present at [build|runtime] (respectively) :)
13:28:04Araqpackage A' uses package A and B.
13:28:07Araqinstead of:
13:28:23Araqpackage A depends on B, optionally.
13:28:32Araqseems to me quite a difference tbh
13:30:56*jjido joined #nim
13:32:00federico3in your example you imagine generating a binary with A' that uses A and B
13:32:47federico3and perhaps have another A" that shares the same codebase as A' and uses only A?
13:34:15AraqI'm not following you.
13:35:02Araqthe point is that when you have 1 (!) "optional" thing, you get a multiplier by 2 (you need to test it with and without) and the "option" is exposed via some flag
13:35:14Araqthis flag can then bubble up
13:35:30federico3sure
13:35:36Araqand so does the multiplier and soon you have x 2 x 3 x 2 x 2 and the test matrix explodes
13:35:43federico3sure
13:36:19Araqand when you say "optional packages are really good, let's have them", it seems like you're advocating for these multipliers but it's intractable
13:36:27federico3...but there is no free lunch here
13:38:27*EvilKhaosKat joined #nim
13:39:53clyybberAraq: I figured out the problem. The VM successfully generates the snippet if I flag the :tmpO sym as sfGlobal..
13:40:01federico3if you want to allow pruning the dependency tree either at compile time or at runtime using dinamic linking you end up having the 2^n configurations in the worst case. Yet you usually restrict the problem space and refuse to compile unneded combinations
13:40:26*dddddd joined #nim
13:40:27FromGitter<deech> Can anyone point me to documentation on the best way to do `ref` copying? So for example given some `ref` `r` and a field `intLists: seq[seq[int]]` and a new `ref`, `r1`, does `r1.intLists = r.intLists` do a deep copy?
13:41:47federico3Instead of flags you can have a different, alternative metapackagages that provide the same tool or lib with different dependencies, but that's just another way of picking subsets of 2^n
13:41:59*Cthalupa quit (Read error: Connection reset by peer)
13:42:24*Cthalupa joined #nim
13:43:05FromGitter<alehander42> clyybber cool idea
13:43:11FromGitter<alehander42> but not sure how often this comes up
13:43:53clyybberAraq: But thats kinda bad, because now all temps are global.. https://github.com/nim-lang/Nim/blob/e0d13abaff1192ae6b1f4ae5cd89ae742627b680/compiler/vmgen.nim#L1646 this is where it fails without the sfGlobal flag.
13:44:12clyybberShould I instead change that condition?
13:44:37clyybberNot sure what logic the VM is following there, so I need some advice
13:44:46Araqclyybber, unfortunately I don't understand your problem
13:45:15Araqdeech: refs are pointers and so only the pointers are copied, 'x = y' vs 'x[] = y[]'
13:45:31Araq(where [] is Nim's pointer deref syntax, it's rarely used)
13:46:17Araqit's very much like in C except that we write x.f instead of x->f (thouh x[].f also works)
13:47:35*Cthalupa quit (Ping timeout: 265 seconds)
13:47:41federico3besides, the 2^n problem is almost a subset of the much larger space when building your package against dependencies at different versions
13:48:42Araqthe 2^n problem can be mitigated by "make up your mind, don't try to depend on X, either do depent or don't"
13:49:09Araqand that's precisely what Nimble does by not supporting "optional dependencies"
13:49:21clyybberAraq: I made a small showcase: https://hastebin.com/okuhukagow.m
13:49:30Araqthough actually I would argue that it does support them already because you can use an 'if' in your nimble file
13:49:34clyybberThe code is from times.nim
13:49:39FromGitter<deech> Araq, in this example the `seq`'s do seem to be copied: ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5db843729825bd6bacec5d4b]
13:50:02clyybberdeech: seqs act like value types
13:50:23clyybberExcept for some rare cases (which are bugs afaik)
13:50:37FromGitter<deech> What are value types?
13:51:05clyybberValue types are types that are copied when assigned.
13:51:31clyybberWith their contents.
13:51:39clyybberLike objects
13:51:50clyybberThe "opposite" are ref objects
13:51:58Araqaha
13:52:10Araqyeah the logic shouldn't care about skTemp, clyybber
13:52:23Araquse skTemp, not skVar
13:52:31Araqand then it should be fine
13:52:46clyybberAraq: I do use skTemp.
13:53:04clyybberSo I need to patch vmgen?
13:54:11Araqlooks like it
13:55:08clyybberHmm, I'll have no idea what I am doing, but I'll try :D
13:55:14FromGitter<deech> clyybber, is there documentation on what types are copied on assignment?
13:55:30clyybberdeech: Everything except ref
13:55:43clyybberAnd ptr
13:55:49clyybberBecause they point to something.
13:55:59FromGitter<deech> clybber: nice, thanks!
13:56:04clyybbernp
13:56:40*Cthalupa joined #nim
13:56:47planetis[m]pretty incompetent to relealize that these are open source projects and i am trying to attract contributors that will help. Instead all i get are a#$%%s asking for "measuring perf regression between java and c", asking to implement generics "right now" and comparing performance between vmulpd and vmulsd...
13:57:15lqdev[m]oh man
13:57:44clyybberplanetis[m]: What project?
13:57:44lqdev[m]seriously tho, comparing java's performance to c feels pretty retarded
13:58:46planetis[m]a linear algebra library
13:59:04planetis[m]Doesnt matter
13:59:27clyybberplanetis[m]: snail?
13:59:49AraqJava's performance can actually be quite good, even when compared to C (Fortran beats C anyway)
13:59:50narimiranlqdev[m]: seriously tho, creating a linear algebra library and not care about its performance, feels.... how exactly?
13:59:52planetis[m]Could be an alt name for it
14:00:36planetis[m]Narimiran: contributions welcome
14:00:58clyybberplanetis[m]: Where is the reop though?
14:01:01clyybberrepo?
14:01:03narimirani use the existing solution: Neo from @andreaferetti
14:01:15narimiranplanetis[m]: ^
14:01:28narimiranand i did some contributions there in the past
14:01:39clyybberplanetis[m]: "snail?" was intended as a question since I saw it today on nimble.directory
14:01:59planetis[m]Then if you need matrix inverse FIRGET IT
14:02:14planetis[m]*Forget
14:02:25FromGitter<alehander42> how is it called
14:02:32narimiranhttps://github.com/b3liever/manu
14:02:38planetis[m]At least its fast! Right
14:02:42narimiranhttps://forum.nim-lang.org/t/5348
14:03:05planetis[m]Whatever
14:03:14narimiranplanetis[m]: https://github.com/unicredit/neo#solving-linear-systems
14:03:37FromGitter<alehander42> ok you got one guy thats a bit rude
14:03:42FromGitter<alehander42> this happens
14:04:35FromGitter<alehander42> however i dont agree with "One library is written in Java, other in Nim, you can't compare apples to oranges."
14:04:38planetis[m]Narimiran: your point is bro?
14:04:42FromGitter<alehander42> this is literally how all people benchmark
14:05:08FromGitter<alehander42> they take similar libs in different lang and compare them, as very often there are additional bottlenecks which arent the language-generated code itself
14:05:11narimiranplanetis[m]: my point is that "Then if you need matrix inverse FORGET IT" is not true when it comes to neo. (which i thought it was aimed at)
14:05:56planetis[m]And what about svd does it have too?
14:06:09Zevvnarimiran: where do I find the Nim CI builds with important packages included?
14:06:26narimiranplanetis[m]: are we gonna play a whack-a-mole until there is something that neo doesn't include?
14:06:33lqdev[m]narimiran: I'm talking about comparing *overall* performance, not specifically this library
14:07:10narimiranneo has everything i needed, and i find it simpler than arraymancer, so i use(d) neo because it was best *for me* and my usecase
14:07:18*jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
14:07:53Araqneo has an interface to Fortran iirc
14:07:54planetis[m]Right from the start i get people saying me (you actually) "use neo" how about no? You dont like my answer?
14:08:30narimiranZevv: e.g. https://ci.appveyor.com/project/dom96/nim/builds/28442597/job/3wjucw03akd2jy4l/tests ?
14:08:32AraqZevv, fixed the VM regression
14:08:41Zevvsweet, thanks!
14:08:44FromGitter<alehander42> it was an answer to your request "contributions welcome" planetis[m]
14:08:48FromGitter<alehander42> please, calm down a bit
14:09:11FromGitter<alehander42> otherwise i think the "no external dependencies to BLAS frameworks."
14:09:15FromGitter<alehander42> is very cool
14:09:25narimiranplanetis[m]: right from the start people give you the advice because they are enthusiastic about what you have done, but you react like they're attacking you
14:09:57planetis[m]Far from the truth
14:10:11narimiranplanetis[m]: so you have a package that is more correct (than arraymancer) and more featured (than neo). now is the time to make it fast so it becomes usable
14:10:18FromGitter<alehander42> what are your plans for it planetis?
14:10:19planetis[m]Far from making a valid point
14:10:29FromGitter<alehander42> do you use it in some project
14:10:48narimiranplanetis[m]: "this is my truth, tell me yours"
14:10:57planetis[m]I use it in my scripts
14:10:57narimiranclyybber: know the reference ^ ?
14:11:35FromGitter<alehander42> but what are they for
14:11:41FromGitter<alehander42> i am interested in how people use actual math
14:11:45planetis[m]I will post on the forum later
14:11:49FromGitter<alehander42> as i rarely do advanced math in my own code
14:12:01FromGitter<alehander42> i used some symbolic math in a compiler toy once
14:12:05clyybbernarimiran: The 90s are calling :)
14:12:11FromGitter<alehander42> very far from algebra :
14:12:32narimiranclyybber: glad you know about it :) i listen it quite frequently :)
14:13:27clyybberQuite the coincidence D
14:13:54narimiran@alehander42 i used Neo for some non-linear dynamics where you simulate some physics phenomena and you have time-steps of size of a fraction of a second. for each time-step you will (multiple times) need matrix multiplications and similar operations — it better be fast!
14:14:32planetis[m]alehander42: civil engineering stuff stiffness matrices and ... i dont really know how the rest are called in english
14:14:52narimiranand if package A is 1000 times (or even 100 times) slower than package B, guess which one will be used?
14:15:07planetis[m]All i ask is this
14:15:32planetis[m]Instead of belittling my efforts
14:15:43planetis[m]Help me out make it fast
14:15:54narimiran"Instead of belittling my efforts" -- nobody is doing that, we're trying to tell you that but you don't listen
14:15:57clyybberplanetis[m]: First comes the problem, then the solution
14:16:27Araqnarimiran, keep it civilized
14:16:43narimiran?
14:16:48planetis[m]instead he post comparisons between laser and manu in github and says its 1000x % slower, thanks a lot
14:17:34narimiran"I inferred from your original post that what you wanted was a pure nim library, I even provided you with a suggestion, by using Laser code, to reach BLAS performance without depending on BLAS."
14:17:34Araqhe is asking for help so either help or be quiet. "package X over there is fast already, everybody uses that instead" is not helpful
14:17:48clyybberplanetis[m]: Huh, how should he help you when he isn't even allowed to phrase the problem first?
14:18:12solitudesfso? why are you upset about it tho? he shoudve instantly submit you a pr rewriting everything for top performance?
14:18:15FromGitter<alehander42> love you all
14:18:17planetis[m]Its open source if it doesnt fit you dont use it
14:18:29FromGitter<alehander42> perf hints are indeed hard to come by
14:18:29clyybberplanetis[m]: And we have free speech
14:18:33narimiranAraq: he already received the help, but he translated it to "mratsim is attacking me"
14:18:44FromGitter<alehander42> often non-obvious things help with performance, good to get help
14:19:18Araqnarimiran, maybe, maybe not. no reason to add to the confusion.
14:19:35narimiranok, lets talk about transpiling then
14:19:36planetis[m]Whe he said that
14:20:25narimiran@mratsim you should join the conversation, to clarify the confusion i'm causing :)
14:20:41Araqsimply shut up and go back to work
14:20:42planetis[m]where was the suggestion?
14:20:49*narimiran left #nim ("Leaving")
14:22:10clyybberplanetis[m]: It wasn't there. But it also doesn't have to be there. But you also don't have to let that get to you.
14:22:28clyybberYou don't have to implement the fastest thing ever.
14:23:21clyybberBut you also have to deal with the fact that people might choose something because its fast.
14:23:45clyybberNobody ever said that producing technology/code is a rewarding thing.
14:24:22clyybberI spent a lot of time understanding and implementing smoothsort only for it to be much slower than quicksort and mergesort.
14:24:40clyybber(Though at extremely high element counts it starts to win)
14:25:34planetis[m]Alehander42: i strongly believe that arguing is better than trying hard not to
14:26:51FromGitter<alehander42> planetis a lot of "arguing" is really leading nowhere
14:26:52planetis[m]Its even more productive and depending on the context and how civilized it is has many benefits
14:26:58FromGitter<alehander42> i bikeshed a lot, so i know :P
14:27:22FromGitter<alehander42> of course, reasonable discussion usually makes sense
14:29:24Araqsmoothsort busts a move.
14:30:15planetis[m]Clybber: thanks for your insight, really love your default fields pr!
14:30:40planetis[m]I have to go, love you all
14:30:44clyybberplanetis[m]: Np, love your zip macro
14:30:48clyybberBb :)
14:31:15*GordonBGood quit (Ping timeout: 240 seconds)
14:31:16clyybberAraq: I wonder how tf djikstra came up with it
14:33:23*nsf quit (Quit: WeeChat 2.6)
14:34:43shashlick@planetis[m] - have you already tried nimprof to profile? i found it helpful for a few simple optimizations
14:38:28*LargeEpsilon joined #nim
14:41:43clyybberplanetis[m]: Thanks, still have a bit to go tho. Fixing bootstrapping rn
14:42:08shashlick@Araq - how do i profile compile time stuff?
14:43:26clyybbershashlick: With cpuTime https://github.com/nim-lang/Nim/pull/12346
14:43:29clyybberhidden behind a flag
14:43:52clyybberoptBenchmarkVm
14:44:13clyybbersorry I mean --benchmarkvm:on
14:45:05shashlickso i'll need to measure manually by inserting calls in appropriate places?
14:47:35clyybberI think so yeah
14:47:53shashlickok well until people complain more about nimterop, i'll hold off for now
14:53:37FromDiscord<kodkuce> make nim greate again
14:53:51clyybberAraq: https://github.com/nim-lang/Nim/pull/12378/commits/67acfdbd38cdcb5f05b3ecb75ada092d9d3a8e77
14:54:55clyybberkodkuce: how to prounce?
14:57:18FromDiscord<kodkuce> what
14:58:34*EvilKhaosKat quit (Quit: This computer has gone to sleep)
14:59:39*EvilKhaosKat joined #nim
15:01:36clyybberkodkuce: proncication
15:02:03FromDiscord<kodkuce> what? kodkuce how it sounds?
15:02:32clyybbernah, I'm just messin with ya :D
15:04:44FromDiscord<kodkuce> kod kuće << google translate set to serbian and play it
15:05:36FromDiscord<kodkuce> https://translate.google.com/#view=home&op=translate&sl=sr&tl=en&text=kod%20ku%C4%87e
15:05:49FromDiscord<kodkuce> aprox, make nim greate again xD
15:11:44FromDiscord<mratsim> @narimiran, @planetis: I'm there. People were asking for performance of Manu, I expressed my concerns that the code will be slow. I then came back with an actual benchmark to back my claim.
15:12:09FromDiscord<mratsim> Regarding the ergonomics, I said that using *. instead of .* was a good idea
15:12:38FromDiscord<mratsim> I provided suggestions to improve the performance of Manu up to BLAS speed without introducing a new dependency on BLAS
15:13:29FromDiscord<mratsim> Saying that I'm not helpful and spend my time showing off is completely misrepresenting what I'm doing.
15:13:55FromDiscord<mratsim> `*.` instead of `.*`
15:19:09FromGitter<zetashift> I also didn't read any ill intentions in that post, but I do think this escalated a bit unnessecary? Keeping that discussion in that thread if best imo
15:30:37Araqclyybber: good enough
15:30:48clyybbernice
15:35:34*ng0 quit (Quit: Alexa, when is the end of world?)
15:36:50FromGitter<zaphodef> hi! is there a way i can force Nim to include all the functions from a module (even if not used) when compiling with --app:staticlib?
15:40:37AraqI doubt it, the compiler is aggressively throwing stuff away
15:41:03FromGitter<zaphodef> arf
15:41:39FromGitter<zaphodef> i want to create Nim signatures for IDA (haven't found any yet)
15:41:50FromGitter<zaphodef> and that was the easy way to do it ahah
15:42:00FromDiscord<mratsim> you need to tag everything with exportc
15:42:17FromDiscord<mratsim> in the past Nim didn't do deadcodeelim by default but now it does.
15:42:44FromDiscord<mratsim> you can probably push exportc pragma to all proc within a module though
15:42:45FromGitter<zaphodef> ok, gonna try this
15:43:18FromGitter<zaphodef> i can push pragmas to procs in imported modules?
15:43:33FromGitter<zaphodef> or you mean rather "as a header thing" in the modules
15:44:41FromDiscord<mratsim> See https://github.com/nim-lang/Nim/issues/10824#issue-419678613 to push the inline pragma on several proc definition
15:45:30FromDiscord<mratsim> more precisely: https://nim-lang.org/docs/manual.html#pragmas-push-and-pop-pragmas
15:45:50FromGitter<zaphodef> cool thx!
15:49:27*letto_ joined #nim
15:51:53*letto quit (Ping timeout: 276 seconds)
15:57:29FromGitter<zaphodef> it doesn't look to work with the import statement, i'm using include instead, but still some issues (eg. https://github.com/nim-lang/Nim/blob/5ba932e43c9c971555d8fdc9e25e2edcdcdd70b4/lib/pure/asyncdispatch.nim#L188 doesn't except the `exportc` pragma)
15:58:05FromGitter<zaphodef> i guess i'll have to do something dirtier and add pragmas directly to .nim lib file
16:01:15FromDiscord<mratsim> ah you want to add that to the stdlib, mmm
16:01:16Araqyou could try to patch incrtl.nim
16:01:42Araqthe stdlib uses .rtl
16:01:54Araqand quite consistently
16:02:07Araqincrtl.nim defines what .rtl actually means
16:04:23FromGitter<zaphodef> ok gonna have a look at it
16:06:04Araqand if you have to add more .rtl pragmas via a PR it's likely to be accepted
16:06:29FromGitter<zaphodef> noted :)
16:06:30Araqbecause it already exists
16:07:44FromDiscord<exelotl> lmao I was tweaking a glsl fragment shader and I saw the word 'discard' in a branch... So I assumed it did the same thing as in Nim, and started using it myself
16:08:43FromDiscord<exelotl> Then suddenly my mesh was full of holes because I was actually discarding pixels xD
16:09:32*Hideki_ quit (Remote host closed the connection)
16:10:18*Hideki_ joined #nim
16:15:00*Hideki_ quit (Ping timeout: 265 seconds)
16:19:03*EvilKhaosKat quit (Quit: This computer has gone to sleep)
16:27:19clyybberlol
16:30:15*abm quit (Quit: Leaving)
16:30:31*Kaivo quit (Quit: WeeChat 2.6)
16:33:22*LargeEpsilon quit (Ping timeout: 265 seconds)
16:35:55zedeusexelotl: what are you working on? i noticed you've been star'ing a lot of game dev related repos
16:53:05FromGitter<zacharycarter> yes - discard actually discards the fragment
16:56:54FromDiscord<mratsim> @Araq, were unsigned included by mistake in range changes? https://github.com/nim-lang/Nim/issues/12554
16:59:16FromDiscord<mratsim> Seems like it's a side-effect of this: https://github.com/nim-lang/Nim/blob/devel/changelogs/changelog_1_0_0.md#breaking-changes-in-the-compiler
16:59:40*ng0 joined #nim
17:24:19*shashlick quit (Remote host closed the connection)
17:36:24*ng0 quit (Quit: Alexa, when is the end of world?)
17:38:15*Hideki_ joined #nim
17:39:05*shashlick joined #nim
17:42:13*letto joined #nim
17:43:41*letto_ quit (Ping timeout: 250 seconds)
17:48:05lqdev[m]this is so nice: https://play.nim-lang.org/#ix=208V
17:48:51*ng0 joined #nim
17:49:06FromDiscord<exelotl> zedeus: well I'm currently doing threejs stuff in my day job. But besides that I'm working on a GBA game in Nim
17:49:43clyybberlqdev[m]: Whats that?
17:49:51FromDiscord<exelotl> here's a (kinda old) gif https://twitter.com/hot_pengu/status/1137819284246323203
17:49:55clyybberDo you mean dumptree in general?
17:50:46lqdev[m]clyybber: no, I mean the `Bracket` syntax and the fact it's parsed correctly
17:50:59lqdev[m]I don't know if it's used anywhere in the language, but it's nice
17:51:04FromDiscord<kodkuce> SDL2 or using some engine, i plan to use Godot + Nim or if must C++
17:51:29clyybberlqdev[m]: Yeah thats cool
17:51:43clyybberexelotl: Damn thats fucking awesome
17:51:55clyybberDo you have a git repo?
17:52:15clyybberI love the GBA
17:52:23lqdev[m]I plan on using it for my Wren wrapper for annotating special procs, like `[new]`, `[init]`, `[get]`, and maybe others
17:52:40FromDiscord<exelotl> I do but it's currently private :x
17:53:10FromDiscord<exelotl> tho I made libtonc bindings which are here https://github.com/exelotl/nim-tonc
17:53:43lqdev[m]@exelotl: damn, your animations are so fluid in this game
17:53:47FromDiscord<exelotl> makes it easy to get up and running if you want to try nim gba dev for yourself ;)
17:53:55clyybberexelotl: Thanks thats really all I wanted
17:53:57clyybberawesome
17:54:17lqdev[m]I love the sprites
17:54:26zedeusexelotl: that's really cool, good job!
17:54:33*LargeEpsilon joined #nim
17:54:51FromDiscord<exelotl> thanks :) I'm lucky and teamed up with a really great artist who I met through work
17:55:03FromDiscord<exelotl> (guy who did the tweet)
17:55:49clyybbercongrats to you both!
17:56:00clyybberthats really slick looking
17:56:17zedeusreplace twitter.com with nitter.net to see my project :)
17:57:34clyybberzedeus: Oh, nice
17:57:39clyybberA twitter frontend?
17:57:55zedeusyeah, click the i logo in the top right for more info
17:58:26*Hideki_ quit (Ping timeout: 240 seconds)
18:02:39clyybbercool
18:03:43clyybberhttps://www.youtube.com/watch?v=atcKO15YVD8 this is interesting
18:04:02*fanta1 quit (Quit: fanta1)
18:07:30*jjido joined #nim
18:07:44clyybberexelotl: Ha, you're coming from LOVE too?
18:08:38*EvilKhaosKat joined #nim
18:11:03*NimBot joined #nim
18:11:47FromDiscord<exelotl> Yeah! Done quite a bit with it over the years :)
18:12:13clyybberexelotl: I always wanted to replicate luas coroutines in nim
18:13:24clyybberbecause lua + love was really fucking perfect
18:13:44clyybberbut too slow, so I switched to nim. Now I love both
18:14:48FromDiscord<exelotl> yeah I get what you mean, I made this but it's more like a super crippled async/await https://github.com/exelotl/ecolo
18:15:33disrupteklove has a nim version?
18:15:37FromDiscord<exelotl> it doesn't do any allocation though so it's suitable for implementing a dialogue/cutscene system on the GBA
18:16:45FromDiscord<exelotl> disruptek: I wish x)
18:20:01clyybberdisruptek: Nope
18:20:19*Trustable joined #nim
18:22:06clyybberdisruptek: But it has a rust version..
18:22:10clyybberIn some way.
18:22:28clyybberOne should in theory be able to call rust from nim
18:28:35FromDiscord<Chiqqum_Ngbata> Nim rulez
18:29:57clyybberheck yeah
18:32:22clyybberAraq: Somehow `high(int)` ends up in cgen
18:32:42clyybberIt should have gotten rid of in semfold right?
18:33:05*jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
18:38:00*EvilKhaosKat quit (Quit: Leaving)
18:38:17*LargeEpsilon quit (Ping timeout: 276 seconds)
18:40:06lqdev[m]clyybber, disruptek: it should be relatively easy to make a LOVE wrapper for Nim using importcpp
18:40:20lqdev[m]the implementation is separate from the Lua wrapper
18:45:41clyybberYeah
18:49:22*nsf joined #nim
19:15:39*floppydh quit (Quit: WeeChat 2.6)
19:27:33FromGitter<Julioevm> Hey everybody, can I specify in a for loop the increment of each iteration?
19:27:39FromGitter<Julioevm> I dont see it in any example
19:27:53zedeushttps://nim-lang.org/docs/system.html#countup.i%2CT%2CT%2CPositive
19:28:34FromGitter<Julioevm> thanks!
19:30:44Araqclyybber: yes
19:30:51clyybberAraq: Fixed it just now.
19:31:24clyybberBootstrapping *almost* works now :)
19:31:39disruptekgood enough.
19:32:09clyybberdisruptek: gcc errors are good enough, I agree :p
19:34:45*sacredfrog joined #nim
19:41:18FromGitter<mratsim> At one point the selling point of Clang was better errors than GCC
19:42:46disrupteknothin' quite like a good compiler error to warm the cockles on a cold, cold night.
19:42:50zedeushaving some macro troubles with object variants
19:42:52zedeushttps://play.nim-lang.org/#ix=209t
19:43:26zedeusif the `of select` branch is moved below `checkbox` in the type definition, it works
19:43:46zedeusi have no idea what's going on here
19:49:07Araqclyybber: read my ideas about 'lent T'?
19:49:45clyybberAraq: Nope, where?
19:50:05clyybberOr do you mean the idea that it's a good idea in general, not just for nrt?
19:50:56clyybberzedeus: Your snippet works for me as is..
19:51:17zedeusdefaultOption gets set to "\x00", but I can make a stronger case, one second
19:53:03Araqno I mean there is no reason to implement 'lent T' as a pointer
19:53:03clyybberk, (be aware that case objects don't really work at ct/as consts)
19:53:12clyybberAraq: Ah
19:53:15clyybberYeah, I agree.
19:53:26zedeushttps://play.nim-lang.org/#ix=209z
19:53:28Araqit can simply copyMem the object and it doesn't have a destructor
19:53:46zedeusdefaultInput and placeholder are empty here, if the select branch is moved up that one is affected instead
19:54:01zedeusthey don't? if i type it manually (still for ct) it works fine
19:54:44clyybberAraq: Yeah.
19:57:03clyybberAraq: We should probably the already implemented heuristics.
19:57:43clyybberzedeus: Yeah, as you can see its unreliable.
19:58:01clyybberSo better not rely on it. According to Araq they are not supposed to work
20:00:25zedeusalright, it works fine as a normal object with empty fields so it's not really an issue
20:00:29zedeusthanks
20:00:52clyybbernp
20:02:28Araqconst `name` = toOrderedTable() --> let `name` = toOrderedTable()
20:02:45Araqwe should really have fixed this for 1.0
20:03:16Araqand tell people to rewrite their code, it never worked reliably
20:03:19Araqoh well
20:03:28zedeusthe table is used during compile-time only, does that work?
20:05:30Araquse a .compileTime pragma too then
20:07:14zedeusthat caused some uh, errors https://play.nim-lang.org/#ix=209D
20:08:11clyybberAraq: Why not make lent default then?
20:08:25Araqdefault for what?
20:08:35clyybberReturn type
20:08:45clyybberMake it copy when it would outlive its origin
20:09:42Araqhmmm
20:10:12AraqI doubt it's sound, the borrowing rule currently requires we derive the location from the first parameter
20:11:03Araqand a shallowcopy still requires a borrowing rule
20:12:43Araqyeah, don't change that, proc p(): T means it returns a fresh T, proc p(): lent T means it returned a view into the T
20:13:02Araqand given that Nim doesn't have C++styled constructions the defaults fit
20:13:12Araq*constructors
20:22:05*tiorock joined #nim
20:22:05*rockcavera is now known as Guest4114
20:22:05*Guest4114 quit (Killed (sinisalo.freenode.net (Nickname regained by services)))
20:22:05*tiorock is now known as rockcavera
20:24:46*d-nice2[m] joined #nim
20:27:01stefantalpalaruAraq: Fortran lost its advantage over C since C99 introduced the "restrict" keyword that tells the compiler that a pointer will not be aliased: https://en.wikipedia.org/wiki/Restrict
20:27:37Araqthat's what you think, yes.
20:27:41*nsf quit (Quit: WeeChat 2.6)
20:27:50*Hideki_ joined #nim
20:28:05Araqin practice there is some value in builtin matrix operations you don't have to extract from nested for loops
20:29:05*filcuc quit (Ping timeout: 264 seconds)
20:31:04FromGitter<Julioevm> what should be used instead of isDigit, since its deprecated?
20:32:57*Hideki_ quit (Ping timeout: 240 seconds)
20:33:00stefantalpalaruJulioevm: https://github.com/status-im/nim-chronicles/pull/64/files
20:44:17*jjido joined #nim
20:47:31*Trustable quit (Remote host closed the connection)
20:53:19clyybberAraq: What types should I skip to check wether the type is and obj or ref obj type in transf?
20:53:38clyybberAnything more than tyGenericInst?
20:56:07clyybberProbably the whole abstractInst, right?
20:56:09*jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
20:59:14*jjido joined #nim
21:01:14*kungtotte quit (Ping timeout: 240 seconds)
21:04:32FromGitter<mratsim> @Araq I agree with @stefantalpalaru, restrict allowed C to bridge the perf gap with Fortran
21:07:46Araqgood for you, I explained my reasoning though
21:10:03*jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
21:10:28AraqFortran compilers optimize Fortran code, C compilers fail at advanced common subexpression elimination ;-)
21:18:25Araqclyybber: abstractInst
21:21:44*letto_ joined #nim
21:23:23*letto quit (Ping timeout: 276 seconds)
21:24:00clyybberAraq: Done
21:24:09clyybberAnd finally bootstraps now \o/
21:25:18*GordonBGood joined #nim
21:30:30GordonBGoodAraq: would you consider making `shallow` and `shallowCopy` depreciated in light of seqsv2 in version 1.1?
21:31:04Araqthat's your concern? still?
21:31:39GordonBGoodNo, not a concern, it's already nooped, just they don't make sense anymore
21:32:36GordonBGoodThe deeper into this I get the more I realize how ugly legacy seqs and strings are any the more I want to erase any signs they were ever there ASAP
21:33:00FromGitter<nixfreakz_twitter> trying to cross compile to windows from osx and it compiles but no exe output ? nim c -d:mingw-w64 control1.nim
21:33:29GordonBGoodAlso, part of what you have given me needs to be updating the docs to reflect how it now works
21:34:09Araqcheck out my araq-refcounting branch
21:34:28GordonBGoodOkay, will do
21:35:45FromGitter<nixfreakz_twitter> am I missing an output flag ?
21:36:55GordonBGoodAlso, deep into getting rid of bypassing PGenericSeq and realized the having a len in the outer object with cap, etc in the payload is kind of redundant, that it would actually make more sense for len to be part of the payload
21:37:56GordonBGoodit would work because there is already code to check if the payload ref is nil, in which case len (and cap) need to be zero anyway
21:38:53GordonBGoodIn other words, put the special case code handling the ambiguity between zero len and nil payload pointer into one place
21:42:04Araqlen is not in the payload
21:42:09*nif quit (Quit: ...)
21:42:13Araqthere is no redundancy
21:42:20*nif_ joined #nim
21:47:07GordonBGoodYes, I know len is not in the payload, I'm saying that with v2 there doesn't seem to be a reason it couldn't be in the payload?
21:48:33GordonBGoodthe code allows for nil payload pointer as it needs to for default seqs, which will automatically have zero len and nil pointer
21:49:09GordonBGoodI'm saying nil payload pointer is enough
21:49:43*superbia joined #nim
21:51:04GordonBGoodOn the other side of ref counting, I am looking at your araq-refcounting branch and see you have gone ahead with the gchooks and simplifying gcdestructors - I like it
21:52:35GordonBGoodOnce seqv2 is totally disassociated with gchooks, there isn't much left (if anything) of destructors in gchooks
21:53:18FromGitter<nixfreakz_twitter> Hint: operation successful (15436 lines compiled; 3.133 sec total; 15.977MiB peakmem; Debug Build) [SuccessX] no exe file though ?
21:58:00clyybberGordonBGood: I'm not opposed to the idea, I guess it saves some bytes. But I wonder if it has any impact I'm not aware of.
22:00:43GordonBGoodThere are still a couple of places in system.nim in your refcounting branch where usesDestructors is used as the switch when it should be nimSeqV2: in the two places getting rid of system/assign and deepCopy
22:02:29GordonBGoodclyybber: if I thought it had much of an impact, I wouldn't suggest it; I'm asking for permission to pursue it, but if it turns out to have a big impact I'll back off
22:03:19clyybberCool, then go ahead! It's a really great idea.
22:03:34GordonBGoodThere needs to be some logic to do with len when the pointer payload is nil, but that is minimum
22:03:52clyybberpointer payload?
22:03:59clyybberYou mean the pointer to the payload?
22:04:04GordonBGoodand much of it is already there, the payload pointer needs to be checked anyway
22:04:42clyybberIf its nil, treat it like len = 0, I'd say.
22:04:44GordonBGoodYes, payload pointer = pointer payload ;-)
22:05:02clyybberk :)
22:05:02GordonBGoodYup, that's my thinking
22:05:49GordonBGoodYou okay on it, but I want to see what Araq thinks before doing anything
22:06:20GordonBGoodseqv2 is a new structure anyway, and as long as the seq/string API stays the same?
22:09:00Araqthat means x.len is translated into a conditional as before
22:09:20AraqI don't think it's wise
22:11:37GordonBGoodAraq, OK, I suppose the advantage of a len field in the outer object is that as long as we make sure it's always valid, it can be accessed without a proc?
22:12:06GordonBGoodWhere cap is a field that is not accessible to the user
22:12:26GordonBGoodAnd if it were, would need a proc
22:13:26GordonBGoodOkay, I'll leave it, it was just an idea
22:14:35*shadowbane quit (Ping timeout: 268 seconds)
22:15:01*shadowbane joined #nim
22:15:05GordonBGoodAraq, on your refcounting branch, note the two places I note above that should be switched on nimSeqsV2 not usesDestructors - to do with seqs changes, not destructors
22:16:31GordonBGoodI'm in process of doing that, seqsv2 won't work with system/assign or deepCopy, of course, which is why we like them :)
22:16:58GordonBGoodassign and deepCopy are UGLY
22:18:18Araqsure
22:19:03GordonBGoodOK, you can change your branch, I am working based on devel
22:19:40Araqalright, but I need to sleep, good night
22:20:02clyybbergn8
22:20:15GordonBGoodYeah, I need to sleep, too, get up in the middle of the night to catch everybody, good night
22:22:37*shadowbane quit (Ping timeout: 240 seconds)
22:24:03FromGitter<mratsim> I naively prefer not having to dereference the seq to know it's length
22:25:07FromDiscord<kodkuce> so you solved nim becoming magic
22:26:48superbiais there a list of javascript supported modules?
22:31:38*tklohna_ quit (Ping timeout: 276 seconds)
22:36:37*solitudesf quit (Ping timeout: 250 seconds)
22:38:44FromGitter<mratsim> I think when they are unsupported it's mentioned in the docs
22:39:10FromGitter<mratsim> But basically it's the low-level stuff like endians, bitops
22:40:36clyybberGordonBGood: Good night
22:46:39*letto_ quit (Ping timeout: 268 seconds)
22:55:36*nif_ quit (Quit: ...)
22:55:45*nif joined #nim
22:59:01*LargeEpsilon joined #nim
23:17:20clyybberkrux02: This is what I'm testing defaultfields with currently: https://hastebin.com/utofalatof.php
23:20:05krux02why isn't it in the PR yet?
23:20:19clyybberkrux02: No particular reason
23:20:29clyybberMainly because I still have some things to do.
23:20:36krux02ok
23:20:50clyybberLike making `case b: bool = true` actually parse
23:20:58krux02I constantly get these notification that you do something there, like two line changes and stuff like that
23:21:16clyybberOh, sorry. I think you can unwatch the PR
23:21:19krux02I have no clue what you are actually doing, but I see that some activity is tthere
23:21:56clyybberkrux02: Heh, yeah my commit messages were a bit wonky. I fixed bootstrapping basically. Skipped some types here and there.
23:22:07krux02yes I can, but I don't want to, because this is a feature that I see particularly dangerous if it is implemented too openly.
23:22:36clyybberkrux02: Hehe, I'm eager to recieve your critique
23:22:44krux02I honestly think that good intentions with too much thinking in this PR can make the language accidentally much worse
23:22:52clyybberI agree.
23:23:21krux02I still say strogly no to all default values that would require an allocation.
23:23:36krux02And that is what I want to see reflected in the test cases as well.
23:24:04krux02A test that ensures an error message when somebody tries to default a seq/string member.
23:24:13clyybberkrux02: Sure
23:25:01krux02By now I also know how people tick, so I want to ensure people gen an idea of the reasoning why those default values would not be allowed.
23:25:19clyybberkrux02: Btw, wdyt: Should the discriminator in case-object constructors be required to be a const?
23:25:29clyybberBecause currently my PR doesn't rely on it.
23:26:05krux02When people see "not implemented" it triggers them, and they might just implement that missing feature, and worst case it migt be accidentally ber merged, because it won't break existing code.
23:26:24*lritter quit (Ping timeout: 252 seconds)
23:26:42krux02but currently I am really worried a lot that Nim will allow too much because people request and implement it without thinking oubt oth consequences of it.
23:27:03krux02I don't want Nim to become this horrible mess that C++ is right now.
23:27:06clyybberkrux02: Not to worry, I am thinking about my stuff :)
23:29:24clyybberkrux02: Wdyt about my above question?
23:32:32*Vladar quit (Quit: Leaving)
23:33:00*LargeEpsilon quit (Ping timeout: 252 seconds)
23:35:40*lritter joined #nim
23:35:58clyybberdisruptek: I might have to disappoint you,
23:36:03disruptekoh?
23:36:08disruptekno more errors?
23:36:19clyybberwhile currently my PR supports non-constant discriminators
23:36:26clyybberI'm thinking about changing it back
23:36:32*nif quit (Quit: ...)
23:36:43*nif joined #nim
23:36:57clyybberbecause look at it that way: with forcing that const condition we guarantee that object construction will work.
23:37:11clyybberand cannot fail.
23:37:26clyybberwhich also seems to be what krux02 is wary of to preserve
23:38:06clyybberdisruptek: Also it makes the implementation much more simple :p
23:38:30disruptekfor the compiler, but not for the user.
23:38:44clyybberI'd argue perhaps also for the user.
23:39:02disruptekit needs to be fixed with dfa, i think. then everyone wins.
23:39:15clyybberBecause 1. Slightly better warnings with --newruntime 2. Object construction can't fail
23:39:16krux02It is also important that the implementation is maintainable. The team of the Nim maintainers isn't big.
23:39:35clyybberkrux02: No worries. It is very simple.
23:39:46disruptekhey, i didn't demand that it was impl. i just said i was sad about boilerplate.
23:42:08clyybberHmm. I'll ask Araq tomorrow what he thinks.
23:42:10krux02well, if `memset(&t, sizeof(t), 0)` can be replaced logically with a `memcpy(&t, defaultT, sizeof(t))`, I am happy.
23:43:03clyybberI don't think we should go that deep. If people want to memset their stuff let them do.
23:43:17*lritter quit (Ping timeout: 240 seconds)
23:43:23krux02I don't literally mean memset
23:43:36clyybberGood
23:43:36krux02I mean the code that Nim generates
23:43:49clyybberkrux02: I'm transforming the object contructors.
23:43:49krux02default values should be set somehow
23:44:07krux02if that "somehow" can be "memset" I am heppy. I don't demand it to be memset.
23:44:15clyybberkrux02: In an earlier implementation I was doing it in the backend, now I'm doing it in transf.nim
23:44:46krux02well, you need to test it for at least, js c++ C and the vm.
23:45:16clyybberkrux02: Do that already.
23:45:23clyybberBut it still isn't finished
23:45:28krux02yea
23:45:34clyybberAnd I don't really like the current implementation
23:46:09krux02yea I can see that. I see code punching that is happening ;)
23:46:20clyybberYeah :D
23:48:04rayman22201"code punching" lol. I like that phrase :-P
23:50:48*krux02 quit (Remote host closed the connection)
23:53:14clyybberGood night y'all
23:53:16*clyybber quit (Quit: WeeChat 2.6)
23:53:45*clyybber joined #nim
23:54:01clyybberForgot to say: good morning rayman :p
23:54:02*clyybber quit (Client Quit)
23:55:09rayman22201lol. It's afternoon for me, but thanks anyway. have a good sleep :-)
23:59:51*Hideki_ joined #nim