<< 13-05-2018 >>
00:00:31dom96data-man: probably separate
00:00:39dom96You can depend on Nimble as a library in your tool
00:04:05FromGitter<data-man> @dom96: I thought to add it to packages repo as package_stats.nim :)
00:07:50*athenot joined #nim
00:10:05FromGitter<data-man> Why Nim 0.13 used in Travis for compiling the package_scanner?
00:26:49*Hashirama joined #nim
00:31:36*CodeVance joined #nim
00:40:07*HYP3RBOR3A_ joined #nim
00:40:14*athenot quit (Ping timeout: 246 seconds)
00:44:04*HYP3RBOR3A quit (Ping timeout: 260 seconds)
00:45:08*Hashirama quit (Quit: Leaving.)
00:46:01*max3 quit (Quit: Connection closed for inactivity)
01:05:24*cspar joined #nim
02:07:06*Hashirama joined #nim
02:18:28*Hashirama quit (Quit: Leaving.)
02:38:54*athenot joined #nim
02:42:43*CodeVance quit (Quit: Yaaic - Yet another Android IRC client - http://www.yaaic.org)
02:45:11*CodeVance joined #nim
03:11:32*athenot quit (Ping timeout: 265 seconds)
03:30:44*xkapastel quit (Quit: Connection closed for inactivity)
03:39:39*SenasOzys quit (Ping timeout: 260 seconds)
03:50:43*SenasOzys joined #nim
04:14:24*Snircle quit (Quit: Textual IRC Client: www.textualapp.com)
04:22:58*leru joined #nim
04:30:57*leru_ joined #nim
04:31:54*darithorn quit (Quit: Leaving)
04:34:53*leru quit (Ping timeout: 256 seconds)
04:35:39*SenasOzys quit (Ping timeout: 260 seconds)
05:02:42*cspar quit (Ping timeout: 265 seconds)
05:05:39*cspar joined #nim
05:16:52*athenot joined #nim
05:20:44*miran joined #nim
05:41:48*CodeVance quit (Read error: Connection reset by peer)
05:42:25*CodeVance joined #nim
05:49:50*athenot quit (Ping timeout: 276 seconds)
05:59:44*nsf joined #nim
06:11:34*nolanv joined #nim
07:06:11*miran quit (Ping timeout: 256 seconds)
07:13:56Araqso ... done with rewriting the compiler ...
07:14:26Araqand it bootstraps again, yum
07:15:32FromGitter<girng> hello!
07:16:25FromGitter<girng> im new to nim, but am having some problems with the environmental variables in windows
07:17:20FromGitter<girng> i ran finish.exe, and added the env variable to my path. i checked my enviromental variabls, and it shows `C:\nim-lang\bin`. however, when i open a cmd and type in `nim` it says unrecognized
07:17:27FromGitter<girng> and im following this tutorial: https://nim-lang.org/docs/tut1.html
07:19:05FromGitter<girng> Aww,wow fail. my bad. i had my old C:\nim-lang\ in there from when i did it manually
07:19:09FromGitter<girng> works now ahhaha.
07:23:18CodeVanceinstall.txt
07:23:41CodeVancenvm I see you've got it :)
07:24:07FromGitter<girng> im coming from godot, it uses gdscript language. this syntax feels really good.
07:31:38FromGitter<Varriount> Araq: Neat, any big changes? :D
07:32:36Araqvarriount: eventually all global variables in the compiler will go away and the compiler gets a clean(er) API
07:32:55Araqthe preparations for this have been completed, more or less
07:33:48*SenasOzys joined #nim
07:39:37FromGitter<Varriount> Araq: Neat, I'm looking through the changes now.
07:54:42Araq ## This procedure is exported in the compiler sources, but its implementation
07:54:42Araq ## is too Nim-specific to be used by Nimble.
07:54:42Araq ## Specifically, the implementation of ``switch`` is problematic. Sooo
07:54:44Araq ## I simply copied it here and edited it :)
07:54:49Araq^ well thanks for that.
07:55:04AraqI enjoy updating copy&pasted code...
07:59:03FromGitter<mratsim> updating copy-pasted code, sounds like you work in Java/php with stackoverflow as your second screen :D
08:02:48*athenot joined #nim
08:04:29*gmpreussner quit (Ping timeout: 260 seconds)
08:05:18*gmpreussner joined #nim
08:05:21*xkapastel joined #nim
08:06:16*CodeVance_ joined #nim
08:06:50*CodeVance quit (Read error: Connection reset by peer)
08:11:40FromGitter<girng> is there a sublime text auto formatter for nim?
08:14:05FromGitter<Varriount> Not that I know of
08:14:39*thomasross joined #nim
08:20:19FromGitter<girng> is it possible to get the local_server or something from https://nim-lang.org/docs/net.html#Socket?
08:24:15FromGitter<girng> oooo `echo fmt"Server started on {getLocalAddr(socket)}"` got it!
08:26:23FromGitter<girng> https://nim-lang.org/docs/net.html so, some of the proc's mean it can accept a socket? so there is no such thing as a "member variables"? or things that inherit from the socket that we can call with `.dotnotation`?
08:26:37FromGitter<girng> we use a function, then send the socket as a parameter?
08:27:40*rauss quit (Ping timeout: 256 seconds)
08:35:32*athenot quit (Ping timeout: 246 seconds)
08:40:38FromGitter<mratsim> @girng Nim is mostly a procedural language like C is. Inheritance is used only if you need polymorphic collections.
08:42:06FromGitter<mratsim> With unified call syntax, you can use the dot notation like methods are used in OO languages `socket.connect(port = 22)`
08:42:35Araqyeah and also the APIs are not designed for "I don't even remember what I passed to the procs, so keep back references to everything I might have forgotten about"
08:43:36Araqwhere everything remembers everything else and then you wonder why it leaks memory even though it has a GC...
08:44:06*vegax87 quit (Ping timeout: 256 seconds)
08:49:26*vegax87 joined #nim
08:50:14FromGitter<girng> @mratsim interesting. im from crystal-lang and nodejs.
08:50:47FromGitter<girng> thanks for explanation ;)
08:51:36FromGitter<mratsim> you’re welcome. I think that’s the main difference with Python syntax is inspired by Python, but programming in Nim is probably more C-like than Python-like.
08:52:09FromGitter<mratsim> I’m not familiar with Crystal though, besides having seen some snippets and benchmarks.
08:52:59FromGitter<girng> @mratsim i been developing with crystal for couple months now. converting my gameserver over. it's been very fun and their community great. i was suggested to look at nim too, and im really like it..
08:53:17FromGitter<girng> i also heard it can utilize all cores for a tcp server.. which is beautiful
08:53:40FromGitter<mratsim> The number of game devs in Nim is quite big compared to the size of the community btw.
08:55:49FromGitter<mratsim> Even Neverwinter Nights Enhanced Edition will use Nim for tooling :O > https://github.com/niv/neverwinter_utils.nim. And there are so many game framework wrappers (Godot, Urho3D, SDL, Unreal, SFML, …)
08:59:01FromGitter<girng> I use godot for my front-end
08:59:33*leru_ quit (Quit: Leaving)
08:59:36FromGitter<girng> im doing a nim server right now just started. im going to be working on how to read a int32 unsigned byte in a tcp stream: https://github.com/godotengine/godot/blob/b48cc669e29ba149664b1e1d6003e112f19a9dff/core/io/stream_peer.cpp#L211
09:01:34FromGitter<mratsim> here you go: https://github.com/mratsim/Arraymancer/blob/master/src/io/io_stream_readers.nim#L7-L9
09:02:07FromGitter<girng> tbh, i actually like this procedural stuff more. although i do like the object orientated from crystal, but i mean tbh i like them both. i just find procedural less intrusive on the coder. because i feel like i'm more free cuz i don't have to wrap stuff in classes all the time
09:02:19FromGitter<mratsim> and the Stream documentation: https://nim-lang.org/docs/streams.html
09:03:12FromGitter<girng> @mratsim very cool
09:06:36FromGitter<mratsim> bigEndian32/littleEndian32 will use optimized builtins from GCC clang if there is a need to swap bytes, otherwise they are no-op so it should be very fast
09:09:02FromGitter<girng> https://paste.ee/p/Ei0uI and when i connect to it, i get `Error: unhandled exception: int(client.fd) <= 0 Client socket needs to be initialised with `new`, not `newSocket`. [AssertionError]`
09:09:45FromGitter<girng> im just following the code here: https://nim-lang.org/docs/net.html#Socket i never changed anything :(
09:10:27FromGitter<mratsim> never used http/sockets in Nim, I’ll try
09:11:05FromGitter<girng> it's weird cause it does compile correctly
09:11:53FromGitter<girng> actually, i take that back. it does give `lib\system.nim(213, 7) Warning: Cannot prove that 'r' is initialized. This will become a compile time error in the future. [ProveInit]` as a Hint
09:15:20FromGitter<mratsim> that’s not an issue. I think the best one to help would be @dom96, also you might find his book useful: https://github.com/dom96/nim-in-action-code/tree/master/Chapter3/ChatApp/src
09:15:29FromGitter<mratsim> it’s a simple chat app using a client server model
09:15:42FromGitter<mratsim> I never used the Nim net module unfortunately
09:15:59FromGitter<girng> ok sweet. i'll check that out then :D
09:16:07FromGitter<girng> give me a good head start maybe :D
09:24:12*Vladar joined #nim
09:34:09*athenot joined #nim
09:54:31*miran joined #nim
10:02:18dom96hey girng, nice to see you trying out Nim :)
10:02:41*athenot quit (Ping timeout: 246 seconds)
10:03:56dom96Araq: At least I added a comment ;)
10:08:12dom96girng: You'll likely want concurrency for your server at some point, so you should probably use 'asyncnet'
10:10:27FromGitter<girng> @dom96 ok awesome
10:10:58dom96And if you want to see how to write a high performance parallel server take a look at httpbeast
10:13:16FromGitter<girng> what's the difference between `{.threadvar.}` and `{.async.}`? just different variable names? what's the `{.` do?
10:13:33FromGitter<girng> im here: https://nim-lang.org/docs/asyncnet.html
10:14:04dom96It's a pragma
10:14:18dom96https://nim-lang.org/docs/manual.html#threads-threadvar-pragma
10:15:06dom96Macros can also be called using pragmas, and that's what {.async.} is: https://nim-lang.org/docs/asyncdispatch.html#17
10:15:53FromGitter<girng> wow that's deep. gona need to read up in this :P
10:16:04FromGitter<girng> that is literally all new to me
10:21:37FromGitter<mratsim> beware, your Sunday might disappear in smoke.
11:05:57FromGitter<girng> :D
11:08:21*CodeVance_ quit (Read error: Connection reset by peer)
11:09:07*jjido joined #nim
11:09:48*CodeVance_ joined #nim
11:23:42*jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
11:46:55*BitPuffin joined #nim
11:48:17*gokr quit (Ping timeout: 248 seconds)
12:10:42*athenot joined #nim
12:18:19*rauss joined #nim
12:24:48*xkapastel quit (Quit: Connection closed for inactivity)
12:26:44*Trustable joined #nim
12:37:27FromGitter<tim-st> how can I find out how much space my `Table` uses?
12:39:55*ofelas quit (Quit: shutdown -h now)
12:42:25*CodeVance__ joined #nim
12:42:59*athenot quit (Ping timeout: 246 seconds)
12:44:14*CodeVance_ quit (Read error: Connection reset by peer)
12:45:47*ofelas joined #nim
12:46:45*CodeVance__ quit (Client Quit)
13:13:27*SenasOzys quit (Ping timeout: 240 seconds)
13:15:46*Snircle joined #nim
13:23:46*cspar quit (Ping timeout: 264 seconds)
13:41:46*athenot joined #nim
13:48:52*Trustable quit (Remote host closed the connection)
13:58:20*arecaceae quit (Read error: Connection reset by peer)
13:58:43*arecaceae joined #nim
14:04:30*Snircle quit (Quit: Textual IRC Client: www.textualapp.com)
14:07:15*CodeVance joined #nim
14:14:53*athenot quit (Ping timeout: 276 seconds)
14:25:02*SenasOzys joined #nim
14:34:33FromGitter<data-man> @tim-st: The most accurate way is to patch table's source. But you can try to use ```getOccupiedMem()```.
14:44:03*yglukhov joined #nim
14:44:32FromGitter<tim-st> @data-man thanks, `getOccupiedMem()` is interesting! I thought `Table` has fields `data` and `counter` but I cant access it
14:48:06FromGitter<tim-st> now it works, I temporarily made both public
14:48:27FromGitter<tim-st> it seems in object types non public fields arent accessable while it is allowed in tuple types
14:49:11FromGitter<zacharycarter> Araq / anyone else involved with Karax - I'm getting this error when I try to require karax with devel via nimble: `/tmp/nimble_8/githubcom_pragmagickarax_0.2.0/karax/karax.nim(31, 21) Error: enable the 'not nil' annotation with {.experimental: "notnil".}`
14:49:19FromGitter<tim-st> Unfortunately it uses much memory :( although my table is const
14:49:21FromGitter<zacharycarter> on debian stretch
14:49:37Yardanico@zacharycarter: not nil became experimental
14:49:43FromGitter<zacharycarter> ah
14:49:51FromGitter<zacharycarter> I'll PR then thanks Yardanico
15:12:47*yglukhov quit (Read error: Connection reset by peer)
15:13:02*athenot joined #nim
15:13:22*yglukhov joined #nim
15:25:43FromGitter<dom96> @zacharycarter I've got a PR open that fixes this.
15:27:40FromGitter<zacharycarter> oh
15:27:46FromGitter<zacharycarter> gd
15:28:06FromGitter<zacharycarter> okay I closed mine
15:28:53FromGitter<zacharycarter> @dom96 - is there a way that I can pull from your fork?
15:28:57FromGitter<zacharycarter> via nimble?
15:31:20FromGitter<tim-st> the following code fails when param is static, was is the reason? https://pastebin.com/P50reqaa
15:31:20FromGitter<dom96> Yeah. You can specify the URL to my fork
15:31:28FromGitter<zacharycarter> okay thanks
15:40:02*edcragg quit (Quit: ZNC - http://znc.in)
15:40:19*edcragg joined #nim
15:45:35*athenot quit (Ping timeout: 255 seconds)
15:55:25*darithorn joined #nim
15:55:52*darithorn quit (Client Quit)
15:57:10*darithorn joined #nim
15:57:12*darithorn quit (Remote host closed the connection)
15:59:11*darithorn joined #nim
16:00:25*miran quit (Quit: Konversation terminated!)
16:05:37FromGitter<Quelklef> Any way to do something like: ⏎ ⏎ ```type Col[2, S: static[int]] = BinCol[S] ⏎ type Col[N, S: static[int]] = NCol[N, S]``` [https://gitter.im/nim-lang/Nim?at=5af862501cfca775e1061a45]
16:06:08FromGitter<Quelklef> bincol and ncol essentially follow the same api but bincol is able to be more efficient knowing N=2
16:06:42FromGitter<Quelklef> so I want to be able to wrap them up together in a type Col since they're conceptually the same, but still reap the benefits of the faster bincol
16:16:24FromGitter<Varriount> @Quelklef You could use an object variant
16:18:54FromGitter<Quelklef> Don't object variants depend on a property of the object rather than its type
16:19:04FromGitter<Quelklef> i mean an attribute
16:19:14FromGitter<tim-st> yes, an enum, you could build your api for NCol and in each proc check `when N == 2` if I understood correctly
16:19:31FromGitter<tim-st> and then give it a custom algo
16:19:59FromGitter<Quelklef> im not sure what you mean, Tim
16:21:08*cspar joined #nim
16:22:16FromGitter<tim-st> Maybe I missunderstood what you want to achieve
16:23:09FromGitter<Quelklef> I want to transparently use a different type for `Col` when N=2
16:23:17FromGitter<Quelklef> I guess that's probably a worse explanation, hmmm
16:24:08FromGitter<Varriount> @Quelklef Sure, but the question then becomes, "how does the compiler retain this type information at runtime"?
16:24:32FromGitter<Quelklef> Well my thought would be that since Nim is structurally typed that wouldn't be an issue
16:24:35FromGitter<Quelklef> or maybe I'm not understanding
16:24:51FromGitter<Quelklef> Like, I'll always use procs that work on both BinCol and NCol
16:25:41FromGitter<tim-st> maybe you could add some example code with a proc that doesnt currently work like you want
16:26:11FromGitter<Varriount> Ok, let's look at an example. I have a sequence of `Col` types, and I invoke a procedure that works on `NCol` or `BinCol`.
16:26:22FromGitter<Quelklef> Sure @Varriount
16:26:33FromGitter<Varriount> (from an element in that sequence)
16:26:40FromGitter<Quelklef> and @tim-st I'll see if I can get one. I'm trying object variants rn though it actually may work
16:27:29FromGitter<Varriount> How does the compiler know whether the underlying`Col` element should be passed to the `NCol` procedure, or the `BinCol` procedure?
16:27:54FromGitter<Quelklef> Ahhhhh, okay. I got it
16:28:18FromGitter<Quelklef> And that kind of thing is what methods are for, yes?
16:28:23FromGitter<Varriount> You can use runtime type information, an object variant, or methods
16:28:43FromGitter<Quelklef> Yeah. Okay, that makes sense. Thank you
16:28:44FromGitter<Varriount> Each have their tradeoffs
16:29:17FromGitter<Quelklef> Generally, I imagine object variants are faster?
16:29:28FromGitter<Varriount> Yes.
16:29:50FromGitter<Varriount> I personally prefer object variants, if all the possible variants are known ahead of time.
16:30:16FromGitter<Quelklef> Really? Even with a lot of them?
16:30:17FromGitter<Varriount> Methods are suitable for when others will be creating variants that you don't know about.
16:31:11FromGitter<Varriount> @Quelklef You would have to do a benchmark to measure performance
16:31:33FromGitter<Quelklef> Yeah
16:31:42FromGitter<Varriount> Also, methods only work with reference types, not object types
16:32:01FromGitter<Quelklef> How come?
16:32:13FromGitter<Quelklef> I think I learned that before and just kinda accepted it but I wondered
16:32:31FromGitter<Varriount> It's due to static typing
16:34:05FromGitter<Varriount> One reason is as follows: I have a sequence containing two types implementing some common interface. The types are references to two different structures.
16:34:53FromGitter<Varriount> Because both types are accessed through references, the sequence's element type is the size of a pointer.
16:34:55FromGitter<sherjilozair> Is this a bug? The program crashes if I remove an unused variable (line 25): https://pastebin.com/zcDaMMW8
16:35:18FromGitter<Quelklef> Right. If it were an object, different sizes would make heterogenous arrays impoisslbe
16:35:36FromGitter<Quelklef> makes sense
16:36:15FromGitter<Quelklef> @sherjilozair Can you give the error message?
16:36:48FromGitter<sherjilozair> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5af869a0bd10f34a68fbacbb]
16:38:06FromGitter<Quelklef> How are you running the program
16:38:10FromGitter<sherjilozair> Also, how can I print something of type `ptr GLubyte`?
16:38:27FromGitter<sherjilozair> Using `nim c -r modern_example.nim`
16:39:50FromGitter<sherjilozair> The generated C code for glutinit seems to be depending on the argc variable .
16:40:15FromGitter<Varriount> @Quelklef An object type is allocated on the stack, or embedded directly in another type's structure. Embedding two object types in a sequence
16:40:54FromGitter<Quelklef> @sherjilozair I'm not sure, but sounds like a bug in glut then
16:41:23FromGitter<sherjilozair> @Quelklef How so?
16:41:43FromGitter<sherjilozair> Shouldn't the compiler be able to detect such bugs?
16:41:50*CodeVance_ joined #nim
16:42:04FromGitter<sherjilozair> glutInit is using something which it did not declare?!
16:42:15FromGitter<sherjilozair> And the compiler is fine with generating code for that?
16:42:27FromGitter<Varriount> Is normally impossible, as the two types are different sizes
16:42:33FromGitter<Quelklef> @sherjilozair I guess that because Nim deals with commandline args in a different fashion
16:42:48*CodeVance quit (Read error: Connection reset by peer)
16:43:08*CodeVance_ is now known as CodeVance
16:43:09FromGitter<Quelklef> @Varriount out of curiosity, you could theoretically do it by padding the types to the larger one's size, right?
16:43:58FromGitter<Quelklef> @sherjilozair glut may be interfacing directly with C, circumventing the compiler. perhaps?
16:44:18FromGitter<Quelklef> yeah 18446744073709551615.0'f64
16:44:19FromGitter<Quelklef> oops
16:44:24FromGitter<Quelklef> https://github.com/nim-lang/opengl/blob/master/src/opengl/glut.nim#L235
16:44:27*athenot joined #nim
16:44:51FromGitter<Quelklef> `proc glutInit` is `{.importc.}`, which is my guess why compiler can't catch the issue
16:45:23FromGitter<sherjilozair> Still doesn't explain why I need to define the argc variable outside of the function call.
16:46:11FromGitter<sherjilozair> As in, whatever glut is doing should be self-sufficient. How come my argc declaration is interfering with whatever glut is doing?
16:47:36FromGitter<sherjilozair> Perhaps the binding is wrong then? The C function expects a couple of variables but nim doesn't provide them in the call?
16:47:41FromGitter<Quelklef> that i cannot answer
16:47:52FromGitter<Quelklef> well actually
16:48:11FromGitter<sherjilozair> In which case nim should check to make sure that the arguments are correct between C and Nim.
16:48:49FromGitter<sherjilozair> i.e. it shouldn't be possible for me to bind nim `proc foo()` to C `void foo(int bar)`.
16:48:55FromGitter<sherjilozair> which I think is what's happening here.
16:49:18FromGitter<Quelklef> Well, is the compilation that straightfoward?
16:49:23YardanicoNim checks that actually
16:49:30Yardanicowell, not nim, but C compiler
16:50:01Yardanico(but not if you create bindings to a .so or .dll)
16:50:03FromGitter<sherjilozair> Yardanico, then this is deviation from expected behaviour.
16:50:18*CodeVance quit (Quit: Leaving)
16:50:35FromGitter<sherjilozair> This is binding to dynlib.
16:51:17FromGitter<sherjilozair> is it not possible to check for type safety when binding against libraries? I'm pretty sure other languages provide this. Maybe not 100%, but this is a pretty common one.
16:51:58Yardanicoare you sure they do? then how?
16:52:24*CodeVance joined #nim
16:52:53*FromGitter quit (Remote host closed the connection)
16:53:01*FromGitter joined #nim
16:57:29FromGitter<sherjilozair> Okay my bad. They use the header information.
16:59:32*HYP3RBOR3A_ quit (Quit: Leaving)
17:11:23*cspar quit (Ping timeout: 256 seconds)
17:13:18Yardanicoas I said, nim can use that too
17:13:43Yardanicobecause nim has c backend by default :)
17:15:21*athenot quit (Ping timeout: 255 seconds)
17:16:13*dddddd joined #nim
17:32:01*miran joined #nim
17:35:57*SenasOzys quit (Ping timeout: 240 seconds)
17:36:33*qwertfisch is now known as wertfisch
17:36:36FromGitter<mratsim> @Quelklef Since 2 or N are known at compile time, use a macro to dispatch on the underlying type like I do there: https://github.com/status-im/nim-stint/blob/master/stint/private/datatypes.nim#L54-L90
17:36:49FromGitter<mratsim> Macro is called here: https://github.com/status-im/nim-stint/blob/master/stint/private/datatypes.nim#L144
17:38:19*vegax87 quit (Changing host)
17:38:19*vegax87 joined #nim
17:38:19*vegax87 quit (Changing host)
17:38:19*vegax87 joined #nim
17:38:51FromGitter<mratsim> Basically depending if N is 16, 32, 64, 128, 256, 512, 1024 … I use uint16, uint32, uint64, 2xuint64, 2x(2xuint64).
17:39:14FromGitter<mratsim> I plan to add native uint128, that would be just a new case in the macro
17:48:47dom96ooh https://nimwc.org/
17:51:09FromGitter<mratsim> @Quelklef here you go: ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5af87b0de1cf621dba1783ba]
17:52:46FromGitter<mratsim> but it might be easier to just dispatch with `when N == 2` in a wrapper inline proc, `when` is done at compile-time.
17:56:27*brainpro1 quit (Ping timeout: 240 seconds)
17:56:53*BitPuffin quit (Remote host closed the connection)
17:58:08FromGitter<mratsim> if you define proc for binCol and NCol, you can use a template to export at the Col level: ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5af87caf9ad18967b9e0f524]
17:58:50FromGitter<mratsim> ```code paste, see link``` ⏎ ⏎ Repost the complete one. [https://gitter.im/nim-lang/Nim?at=5af87cdaa2d951363337e97f]
18:00:29*SenasOzys joined #nim
18:08:48*yglukhov quit (Remote host closed the connection)
18:11:10Yardanicobtw, https://github.com/ThomasTJdev/nim_websitecreator looks cool, but sad thing about it - it's GPLv3, and also I forked it (to change some stuff to be more nim-like)
18:14:12Yardanicoah, well, GPL doesn't really matter in this case AFAIK
18:14:36FromGitter<mratsim> unless your website is a static lib :D
18:14:45FromGitter<mratsim> or dynlib
18:17:30Yardanicoheh, yes :) about the code - it's fine, but author doesn't yet know about features nim has (like this proc - https://github.com/ThomasTJdev/nim_websitecreator/blob/master/src/ressources/utils/dates.nim#L99 can be made much simpler)
18:17:34*athenot joined #nim
18:18:11dom96Let them know
18:18:17FromGitter<mratsim> PR away ;)
18:18:20dom96Also, isn't GPLv3 really restrictive?
18:18:30Yardanicodom96, no, AGPL is
18:18:46Yardanicoas I googled it seems that if your website is AGPL you SHOULD distribute its' code
18:18:50dom96ahh]
18:18:53Yardanicobut with GPLv3 you don't need to do it
18:18:58FromGitter<mratsim> GPLv3 is painful for library because only GPLv3 code can link against it.
18:19:02Yardanicobecause you just provide the output of your GPLv3 program
18:19:52FromGitter<mratsim> but if you don’t distribute anything you’re fine. You don’t need to distribute your source. (i.e. server software)
18:20:42FromGitter<Quelklef> @mratsim this is cool! I have some worries about treading in macro territory, though, so I may just stick with object variants
18:21:37FromGitter<mratsim> object variant means dispatch at runtime, all the efficiency you want to gain will be lost.
18:21:57*jjido joined #nim
18:22:08FromGitter<Quelklef> How come? BinCol's more efficient algorithms are concerned with runtime speed
18:22:11FromGitter<mratsim> otherwise just create overloaded proc, one for BinCol, one for Col.
18:22:17FromGitter<Quelklef> it just means there will be a slight overhead either way, right?
18:23:16FromGitter<Quelklef> Here, actually, since my usage case is fairly narrow I'll try your solution out
18:23:17FromGitter<mratsim> function call (can be inlined) + case statement overhead. Depending on how often it’s called (1 Millions times?) especially in loops, this may become significant.
18:23:34FromGitter<Quelklef> yeah, that's a good point
18:23:44FromGitter<Quelklef> I'll try this out, but I don't totally get how it works
18:24:18FromGitter<mratsim> the macro choose the implementation of Col at compile time
18:24:33FromGitter<mratsim> if N == 2 it’s BinCol that will be in Col.data
18:24:34FromGitter<Quelklef> Right, so what does it mean anymore for a value to be of type `Col`?
18:24:42FromGitter<Quelklef> Oh, wait, `Col` doesn't actually exist, does it?
18:24:46FromGitter<mratsim> it does
18:24:58FromGitter<mratsim> it’s an object with a single field called data
18:25:02FromGitter<Quelklef> right
18:25:11FromGitter<mratsim> data is either BinCol or NCol
18:25:36FromGitter<Quelklef> But exactly how are those both in one type
18:25:40FromGitter<mratsim> so what you do now is define your proc for Col, and your specialized proc for BinCol
18:25:47FromGitter<Quelklef> Is the macro working "outside" the type system, so to speak?
18:25:49FromGitter<mratsim> proc for Col*
18:25:55FromGitter<mratsim> NCol
18:26:08FromGitter<Quelklef> ncol and bincol
18:26:09FromGitter<Quelklef> right
18:26:22FromGitter<mratsim> and then just use the template I provided that will create the exported public proc for “Col"
18:26:46FromGitter<mratsim> you might want to add a {.inline.} pragma to avoid a spurious function call.
18:27:16FromGitter<Quelklef> With what, the templated procs?
18:27:19FromGitter<mratsim> The macro is outside the type system yes
18:27:42FromGitter<mratsim> basically a macro manipulates the abstract syntax tree, if it’s untyped it intervenes before type resolution
18:28:00FromGitter<Quelklef> okay
18:28:09FromGitter<Quelklef> If it's working outside, then I think I get it
18:28:09FromGitter<mratsim> so I intervene before type resolution, ased ont eh value of N, to change the implementation of the type
18:28:16FromGitter<Quelklef> based on the value"?
18:28:20FromGitter<mratsim> yes
18:28:24FromGitter<Quelklef> gotcha
18:29:24FromGitter<mratsim> regarding the template, if you look here: I define the + and += proc for my UintImpl: https://github.com/status-im/nim-stint/blob/master/stint/private/uint_addsub.nim#L24
18:29:46FromGitter<mratsim> but uintImpl are my internal types, like your BinCOl and NCol
18:30:01FromGitter<mratsim> sometimes uintImpl == uint32 or uint64 or 2xuint64
18:30:25FromGitter<Quelklef> I see. But here you're able to just define a proc
18:30:47FromGitter<mratsim> I want to give an unified interface: so I use a template here: https://github.com/status-im/nim-stint/blob/master/stint/uint_public.nim#L21-L27
18:30:59FromGitter<mratsim> https://github.com/status-im/nim-stint/blob/master/stint/uint_public.nim#L36
18:31:46FromGitter<mratsim> this way for all implementation of my public StUint type, whatever the internal type is (uint32, uint64, or UintImpl) it will use the correct `+`
18:31:57FromGitter<Quelklef> Right
18:32:05FromGitter<Quelklef> ok, let me try out exportCol
18:32:52FromGitter<mratsim> if your repo is public, feel free, i can show you on short procs.
18:33:14FromGitter<mratsim> I just need the types, the specialized BinCol proc and the generic NCol proc.
18:34:19Yardanicowhat file mode should I use to append to existing file, and create it if it doesn't exist?
18:34:29YardanicofmReadWrite ? or there's no such file mode?
18:34:41Yardanicoah, no, it rewrites files
18:34:54FromGitter<mratsim> fmAppend?
18:35:11FromGitter<Quelklef> @mratsim github.com/Quelklef/random-algorithms
18:35:16Yardanicoit doesn't create file if it doesn't exist :) so I will do it manually
18:35:31Yardanicoor maybe it does?
18:35:46FromGitter<Quelklef> nColoring.nim and twoColoring.nim are the two types, and coloring2.nim is your implementation of combining them
18:35:53FromGitter<Quelklef> and coloring.nim is object variant solution
18:36:12FromGitter<mratsim> okay, I’ll cook something up :)
18:36:50FromGitter<Quelklef> Thanks! This project depends a lot on speed so that'd be awesome
18:37:02FromGitter<mratsim> or does it work already?
18:37:06FromGitter<Quelklef> Unfortunately not
18:37:22FromGitter<Quelklef> coloring2.nim fails with a type error on line 14: `data: ...`
18:37:31FromGitter<Quelklef> Although I don't think I'm on devel, should I update just in case
18:37:54FromGitter<mratsim> it only works on devel
18:38:02FromGitter<Quelklef> Ok, will get devel
18:40:17*miran quit (Quit: Konversation terminated!)
18:44:09FromGitter<Quelklef> Working better, but still not
18:44:16FromGitter<Quelklef> I'll try to match your examples
18:47:23FromGitter<Quelklef> @mratsim 'Error: redefinition of '+''
18:47:44FromGitter<Quelklef> Is this not an issue with yours because of different files?
18:48:32*athenot quit (Ping timeout: 276 seconds)
18:49:05*brainpro1 joined #nim
18:52:31FromGitter<mratsim> Here you go: ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5af8896f5e8e2175e261581f]
18:52:42FromGitter<Quelklef> holy hello
18:53:46FromGitter<mratsim> I’ve posted it as an issue in your repo
18:54:06FromGitter<Quelklef> I see, sweet
18:54:42FromGitter<mratsim> also, use div if you want floored integer division
18:54:52FromGitter<mratsim> and not 0’u64 if you want high(uint64)
18:55:02FromGitter<Quelklef> div isnt quite right
18:55:07FromGitter<Quelklef> i want ceil integer division
18:55:12FromGitter<Quelklef> i used div before and it caused a but
18:55:18FromGitter<Quelklef> but not 0'u64 is a good call, thanks
18:55:22FromGitter<mratsim> ok.
18:55:24FromGitter<Quelklef> bug*
18:56:01FromGitter<Quelklef> So now does this also allow for definition of procs for general Colorings
18:56:05FromGitter<Quelklef> i.e. both at once
18:56:34FromGitter<mratsim> yes, I didn’t call the internal proc, I called `+=` on the general Colorings object
18:56:58FromGitter<Quelklef> Right, but I mean when writing the proc
18:57:01FromGitter<mratsim> if you change the init(2, 256) to initColoring(3, 256) you will see the internal type change but the proc works too
18:57:21FromGitter<Quelklef> not sure what you mean by that last message
18:57:33FromGitter<mratsim> yes just write the proc with a general coloring input and works on input.data
18:57:41FromGitter<mratsim> work*
18:57:44*xkapastel joined #nim
18:58:01FromGitter<mratsim> they must support the same generic proc but since they are both arrays it should be fine
18:58:27FromGitter<Quelklef> Right
18:58:47FromGitter<mratsim> like proc `$`(col: Coloring) = $col.data
18:58:59FromGitter<Quelklef> Also is there a reason you swapped the init function vars from type vars to function vars
18:59:12FromGitter<Quelklef> like `initColoring(N, S)` instead of `[N, S]`? Just convention?
18:59:58FromGitter<mratsim> it’s more like it’s a necessary parameter for init so and it would be empty otherwise.
19:00:21FromGitter<Quelklef> What do you mean
19:00:22FromGitter<mratsim> also for chaining you might avoid troube, but really that’s your call here
19:00:52FromGitter<mratsim> you have to give the static param to the compiler, it cannot infer it from another input.
19:01:20FromGitter<mratsim> so for me it’s a full param for init, not just a “generic"
19:02:00FromGitter<mratsim> so do as you wish, if you have a weird error at one point, swap. That’s what I’m doing ;)
19:02:09FromGitter<Quelklef> Hm. That makes sense
19:02:12FromGitter<Quelklef> and hah, that's one way to do it
19:03:36FromGitter<Quelklef> Hm, I'm concerned about writing generic procs
19:03:59FromGitter<Quelklef> e.g. ⏎ ⏎ ```proc `$`[S, N: static[int]](col: Coloring[S, N]): string =``` [https://gitter.im/nim-lang/Nim?at=5af88c1f2df44c2d0624ada1]
19:04:20FromGitter<mratsim> it should be $S
19:04:38FromGitter<Quelklef> Oh, ugh, duh
19:06:24shashlickis baabelfish/nvim-nim dead? no updates in over a year
19:08:35FromGitter<mratsim> by the way @Quelklef are you doing just a simple addition in teh += proc? the carry is either 1 or 0 to the uint64..uint128 limb
19:09:19FromGitter<Quelklef> Yeah, overflow can only be 1/0, except that i initialize it to `amt`
19:09:42FromGitter<Quelklef> And yes just addition, am essentially implementing arbitrary static-sized integers
19:09:46FromGitter<Quelklef> (in TwoColor)
19:10:12FromGitter<Quelklef> But what about it only being 1/0?
19:10:45FromGitter<mratsim> ```code paste, see link``` ⏎ ⏎ wil generate the fastest assembly possible [https://gitter.im/nim-lang/Nim?at=5af88db52df44c2d0624b24b]
19:11:10FromGitter<Quelklef> holy shit, thanks
19:11:18FromGitter<Quelklef> you're practically doing this project for me at this point, hah
19:11:32FromGitter<Quelklef> also that could be a cast to be faster, yes?
19:11:50FromGitter<mratsim> doesn’t need to I checked
19:11:56FromGitter<Quelklef> Same speed?
19:12:27FromGitter<Quelklef> Wait this is clever
19:12:36FromGitter<mratsim> see here: https://github.com/status-im/nim-stint/issues/10
19:12:46FromGitter<mratsim> assembly will be ADD, then ADC
19:13:03FromGitter<mratsim> (add, then add with carry)
19:13:21FromGitter<Quelklef> Not entirely sure what I'm looking at
19:13:47FromGitter<Quelklef> But your point is it will compile directly?
19:13:51FromGitter<Quelklef> Either way, I'll take your word for it
19:13:53FromGitter<mratsim> the assembly generated for this: https://github.com/status-im/nim-stint/blob/master/stint/private/uint_addsub.nim#L17-L22
19:15:50FromGitter<mratsim> basically if you have doubt on how to implement stuff for speed for multiprecision computation, have a look into what I did, though I only work on Uint256 + Uint256 not Uint256 + uint64
19:16:30FromGitter<Quelklef> ok
19:16:41FromGitter<Quelklef> I mean, I should be using the largest int type possible
19:16:47FromGitter<Quelklef> I just thought uint64 was the largest
19:18:16FromGitter<mratsim> theoretically you can use uint128 ;) https://github.com/nim-lang/Nim/issues/7675
19:18:44FromGitter<mratsim> but that’s probably a can of worms at the moment, I didn’t have the tyme to wrap them.
19:18:47FromGitter<mratsim> time*
19:18:56FromGitter<Quelklef> Yeah I'm gonna stick to safety lol
19:23:11FromGitter<mratsim> oh another thing, I noticed that those macro on type sometimes make nimsuggest choke.
19:23:29FromGitter<mratsim> so you might have to kill it more often ;)
19:24:10FromGitter<Quelklef> I don't use nimsuggest, anyway
19:24:14FromGitter<Quelklef> don't even know what it is
19:25:36FromGitter<mratsim> aautocompletion for Nim for Vim, VScode, Atom ...
19:25:52FromGitter<Quelklef> Ah, I'm on Kakoune
19:26:04FromGitter<mratsim> Nim reached 104 comments in /r/programming: https://www.reddit.com/r/programming/comments/8ilinf/python_vs_numpy_vs_nim/ congrats @miran
19:28:25FromGitter<diegogub> hello, anyone could help me with this error :
19:28:26FromGitter<diegogub> ... lib/pure/asyncmacro.nim(361, 31) Error: 'matchIter' is not GC-safe as it calls 'handle'
19:28:47FromGitter<diegogub> I'm using jester, and a macro..
19:31:22FromGitter<diegogub> https://github.com/nim-lang/Nim/issues/4744
19:31:26FromGitter<diegogub> I saw this issue..
19:31:45Yardanicowell, your code inside of "routes" section must be gc safe
19:31:53Yardanicoasync implies thjis
19:31:55Yardanico*this
19:33:12FromGitter<Quelklef> @mratsim Seems to be totally working :) thank you!
19:34:23FromGitter<mratsim> awesome =), welcome to macro lala land.
19:34:40FromGitter<Quelklef> A little bit, anyway
19:37:06FromGitter<diegogub> @Yardanico removing --threads:on solved it...but I had to remove all the background process
19:39:37*nsf quit (Quit: WeeChat 2.1)
19:40:40Yardanicowell yeah, with threads and async your async code should be gc-safe
19:46:29*athenot joined #nim
20:03:27*gokr joined #nim
20:03:58*jnhevqjjiupv quit (Ping timeout: 256 seconds)
20:07:36*nsf joined #nim
20:19:38*athenot quit (Ping timeout: 276 seconds)
20:33:28*Vladar quit (Quit: Leaving)
20:33:50*CodeVance2 joined #nim
20:34:34*CodeVance quit (Ping timeout: 265 seconds)
20:34:43*darithorn quit (Quit: Leaving)
20:49:14*nsf quit (Quit: WeeChat 2.1)
21:16:06*jnhevqjjiupv joined #nim
21:20:45*Jesin joined #nim
21:38:47*Jesin quit (Quit: Leaving)
21:39:19*jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
21:54:05*gokr quit (Ping timeout: 240 seconds)
21:57:40*gokr joined #nim
22:10:42*leorize quit (Quit: WeeChat 2.1)
22:17:59*athenot joined #nim
22:34:03*brainpro1 quit (Quit: WeeChat 2.1)
22:50:52*athenot quit (Ping timeout: 265 seconds)
23:01:40*cspar joined #nim
23:21:32*mcc joined #nim
23:43:50*CodeVance2 quit (Ping timeout: 268 seconds)
23:45:33*CodeVance joined #nim
23:47:07*athenot joined #nim