<< 17-03-2018 >>
00:02:18*leorize quit (Quit: WeeChat 2.0.1)
00:07:14*Snircle quit (Quit: Textual IRC Client: www.textualapp.com)
00:23:51*rokups quit (Quit: Connection closed for inactivity)
00:59:35*dddddd quit (Remote host closed the connection)
01:04:36FromGitter<cavariux> Hi araq, as a library is there any way to set the compilation to cpp background or the user has to manually input it?
01:04:55FromGitter<cavariux> oh, two hours of difference he might be gone
01:05:13shashlickyou can use nim.cfg
01:05:49FromGitter<cavariux> but as a library, so that if the user imports a module the background changes, like a pragma?
01:06:36shashlickgood question, I'm not sure
01:06:54FromGitter<cavariux> hmm, I hate the difference on the time zones .-.
01:07:46shashlicktell me about it, just got out of daylight savings time, else they are 6 hours ahead
01:08:45FromGitter<cavariux> yep haha, well it seems like my questio will have to wait until tomorrow
01:12:06*ipjk quit (Read error: Connection reset by peer)
02:03:14*SenasOzys quit (Remote host closed the connection)
02:04:04*SenasOzys joined #nim
02:05:01*SenasOzys quit (Remote host closed the connection)
02:07:36*SenasOzys joined #nim
02:36:24*brainproxy quit (Ping timeout: 260 seconds)
02:39:23*vivus quit (Quit: Leaving)
02:55:43*S1t1Schu joined #nim
02:59:09*S1tiSchu quit (Ping timeout: 260 seconds)
03:08:11*brainproxy joined #nim
03:13:55FromGitter<AjBreidenbach> hey, is there a good way to deal with C consts or pass a string literal for cffi?
03:30:23*endragor joined #nim
03:34:27*endragor quit (Ping timeout: 240 seconds)
03:39:47*zama quit (Ping timeout: 245 seconds)
03:40:11*zama joined #nim
03:41:39*brainproxy quit (Ping timeout: 256 seconds)
03:46:22*brainproxy joined #nim
03:53:47FromGitter<zacharycarter> @AjBreidenbach just do "foo".cstring ?
03:54:53FromGitter<zacharycarter> @cavariux - do you mean like, via a nimble file (configuration) or code?
03:55:13FromGitter<zacharycarter> because you can definitely easily control the backend via nimble
03:55:55FromGitter<zacharycarter> I don't think you can do what you're describing with the whole pragma thing
03:56:14FromGitter<cavariux> Oh, hi zachary, I'm some context that only you will get haha, I started making the imgui bindings but they are made in cpp and even the cimgui can't be fully compiled on a c compiler. So I was wondering the there was a pragma so when the user imports imgui and they want to compile the src cpp backend turns on
03:56:36FromGitter<zacharycarter> I don't think so
03:56:57FromGitter<cavariux> hmm well, they will have to read the docs then because by default imgui will ask for a dll
03:56:59FromGitter<zacharycarter> the compiler is an executable which takes in arguments and one of them is the backend
03:57:46FromGitter<cavariux> btw, how do you use imgui, in terms on what are the most used options? caused all the info I'm getting are from the examples and how they made an integration with glfw and I'm replicating that integration.
03:57:58FromGitter<zacharycarter> that's why you type in - `nim c foo.nim` or `nim js foo.nim` when compiling
03:58:26FromGitter<cavariux> I'm making a wrapper on top of the bindings to port this with the already done glfw bindings
03:58:26FromGitter<cavariux> https://github.com/ocornut/imgui/blob/master/examples/opengl3_example/imgui_impl_glfw_gl3.cpp
03:58:48FromGitter<zacharycarter> I've never used imgui before - but I'm pretty sure you write all the graphics API code, basically providing the backend
03:59:00FromGitter<zacharycarter> it's just like a drawing API layer that is graphics API agnostic
03:59:22FromGitter<zacharycarter> I think there was already some work on some imgui bindings
03:59:30FromGitter<cavariux> oh, well I will expose both, the integration with the glfw and the raw bindings
03:59:35FromGitter<zacharycarter> you may want to study to see if you can bring them into a more stable state
03:59:45FromGitter<zacharycarter> well glfw is just a windowing API
04:00:00FromGitter<cavariux> https://forum.nim-lang.org/t/1820
04:00:04FromGitter<cavariux> The most I can find imgui + nim
04:00:18FromGitter<zacharycarter> one sec
04:00:22FromGitter<cavariux> sure
04:02:16FromGitter<zacharycarter> mmm you are right - I was thinking of NanoVG
04:02:51FromGitter<zacharycarter> give me a few minutes - let me take a look at the ImgUI codebase and I'll try to provide some instruction on where you can start
04:03:30FromGitter<cavariux> great, thanks cause I'm just porting functions that seem important lol and remaking that glfw integration to test
04:05:30FromGitter<zacharycarter> I wouldn't worry about this - ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5aac94098f1c77ef3acd88d1]
04:06:09FromGitter<zacharycarter> it just means you need gcc to compile the library - it doesn't mean you can't use it to bind to
04:06:12FromGitter<cavariux> hmm I tested it and it's using some important functions from the c++ std so I can't use the C compiler
04:06:27FromGitter<cavariux> ohh yeah, all you have to do is provide the dll
04:06:33FromGitter<zacharycarter> yeah
04:06:36FromGitter<cavariux> but only if you use cpp as a backend you will be able to compile it
04:06:44FromGitter<zacharycarter> no
04:06:49FromGitter<cavariux> O.o?
04:06:51FromGitter<zacharycarter> you don't need to compile the library with Nim
04:07:19FromGitter<cavariux> Oh, well, it's easier for cross platform support but if only one lib needs a dll it's okay
04:08:15FromGitter<cavariux> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5aac94aec3c5f8b90d7fd7ad]
04:08:22FromGitter<cavariux> I'm doing that atm
04:09:34FromGitter<zacharycarter> what errors are you getting?
04:10:02FromGitter<cavariux> When using the dll none, but when compiling it pretty much that I don't have the c++ std
04:10:25FromGitter<zacharycarter> oh I see - you're trying to support both
04:10:54FromGitter<cavariux> yep, but the only way to support C is that they provide the dll instead of compiling it
04:10:58FromGitter<zacharycarter> sorry - I just got back from a hockey game and it's midnight so my brain is fried :P
04:11:26FromGitter<cavariux> no worries haha
04:11:36FromGitter<zacharycarter> yeah - this gets very tricky - if you want to see some bindings to a library I know that does this : https://github.com/Halsys/nim-bgfx
04:11:53FromGitter<zacharycarter> I'm pretty sure that guy jumped through some extra ordinary hoops to enable cpp compilation of that library
04:12:33FromGitter<zacharycarter> then again the cpp lib was amalgamated so I can't guarantee it's usefulness to you
04:13:01FromGitter<cavariux> Damn and not a single line of doc hahaha
04:13:22FromGitter<cavariux> and he is supporting also the use of a built lib
04:14:02FromGitter<zacharycarter> yeah - I think he supports both compiling from source and using a pre-built shared lib like you're describing
04:15:10FromGitter<cavariux> but you need to use the cpp backend on bgfx right? cause I don't see another way of compiling cpp code without the cpp backend :/
04:15:19FromGitter<cavariux> ``` {.compile: "bx_amalgamated.cpp".}```
04:15:50FromGitter<zacharycarter> yeah - if you want to compile C++ with the Nim compiler - you need to use the cpp backend
04:16:33FromGitter<cavariux> oh, well, I will add a warning then in the docs for this binding that you either need a dll or use cpp backend
04:16:34FromGitter<zacharycarter> there's no way to switch the backend at runtime via code or anything like that
04:17:04FromGitter<zacharycarter> I recommend just telling people to use the shared library and assume they have the dependent library installed
04:17:12FromGitter<cavariux> not at runtime but it would be cool a pragma like {.backend cpp.} and you can only compile that piece of code with that backend with a stylish error
04:17:28FromGitter<zacharycarter> there may be something like that - I'm not sure
04:17:42FromGitter<cavariux> I just went through all the documented pragmas and nothing :/
04:17:49FromGitter<zacharycarter> I write a lot of bindings - and I just assume the user has the library on their system
04:18:01FromGitter<zacharycarter> if not - they shouldn't be trying to use my bindings anyway :P
04:18:36FromGitter<zacharycarter> there is only a certain degree of hand holding we should do IMO - introducing people to Nim is fine - but we shouldn't spend extra time making their lives easier once they are here
04:18:43FromGitter<zacharycarter> only more productive
04:19:19FromGitter<zacharycarter> so don't worry about people being able to compile a library or whatever for your bindings IMO
04:19:23FromGitter<cavariux> hahaha good point, it's only that I really liked that you could import bindings of almost everthing and they work in almost all platforms
04:19:27*brainproxy quit (Ping timeout: 240 seconds)
04:19:30FromGitter<cavariux> but I guess there's a limit
04:19:36FromGitter<zacharycarter> nimgen is great in this - in it gives you a reusable configuration to produce bindings
04:19:46FromGitter<zacharycarter> well you can always use docker or something too
04:20:06FromGitter<cavariux> I thougm gem was an integration of the ruby gem
04:21:42FromGitter<zacharycarter> I do bindings like this pretty much - ⏎ https://github.com/zacharycarter/nim-sass ⏎ https://github.com/zacharycarter/bgfx.nim ⏎ https://github.com/zacharycarter/nuklear-nim ⏎ https://github.com/zacharycarter/blt-nim [https://gitter.im/nim-lang/Nim?at=5aac97d6e4ff28713a4085ca]
04:22:06FromGitter<zacharycarter> I don't spend a lot of time on them - I upgrade them when someone / me needs them to be
04:22:33FromGitter<zacharycarter> nimgen - https://github.com/genotrance/nimgen
04:23:31FromGitter<zacharycarter> anyway - I gotta catch some zzz's and get up early, have a good night! feel free to PM questions or ask here someone or myself will answer eventually
04:23:41FromGitter<cavariux> nice, I like that nim is getting more useful libraries
04:23:56FromGitter<cavariux> sure, good night hope you rest
04:24:14FromGitter<cavariux> thanks for all
04:24:34*brainproxy joined #nim
04:38:54*picknick joined #nim
04:41:10FromGitter<zacharycarter> https://bitbucket.org/duangle/scopes/wiki/Home - and I'll go to bed
04:43:17*endragor joined #nim
04:43:27*SenasOzys quit (Ping timeout: 240 seconds)
04:58:09*brainproxy quit (Ping timeout: 260 seconds)
05:03:37*brainproxy joined #nim
05:11:50*picknick quit (Quit: picknick)
05:33:24Araqcavariux: you can't set it, but there is some logic in the compiler. if you compile the project with 'c' and a module uses 'importcpp', then that module is compiled as C++ code.
05:33:40Araqunfortunately this logic might have bugs since it never was battle-tested.
05:36:39*brainproxy quit (Ping timeout: 260 seconds)
05:37:15FromGitter<cavariux> @Araq it gives me this error
05:37:16FromGitter<cavariux> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5aaca98bc3c5f8b90d80177e]
05:45:44*brainproxy joined #nim
05:54:04*kat5jh joined #nim
05:54:04*kat5jh quit (Client Quit)
06:15:25*MJCaley quit (Read error: Connection reset by peer)
06:16:03*MJCaley joined #nim
06:18:27*brainproxy quit (Ping timeout: 240 seconds)
06:38:28*brainproxy joined #nim
06:57:15FromGitter<Araq> huh?
06:57:39FromGitter<Araq> that sounds like a different issue
06:58:26Araqhttps://opensource.com/article/18/3/avoid-humiliating-newcomers
07:04:02*nsf joined #nim
07:05:13*arnetheduck quit (Ping timeout: 252 seconds)
07:07:42FromGitter<mratsim> Rephrase it at “Tilt and Open-source dev” and we might get a new stream of ex-poker player and League of Legends ;). Very relevant, indeed. ⏎ I see that in Data Science too. Newcomers coming, great, then people are asking "how do I do X” for 2 months, but at one point it seems like homework?
07:11:29*brainproxy quit (Ping timeout: 248 seconds)
07:23:34*xkapastel quit (Quit: Connection closed for inactivity)
07:23:40*miran joined #nim
07:23:45Araq!eval echo 7 * 27 + 0.25 * 27
07:23:48NimBot195.75
07:24:18Araq3hours, 16 minutes. tough.
07:25:04Araqbbl
07:28:59miranAraq: your example above - is this some new behaviour (that you can mix floats and ints)? i remember i had to convert ints to floats before. or did i misremember something?
07:29:05*brainproxy joined #nim
07:31:33FromGitter<mratsim> Someone wants to start a PS2 emulator counterpart to NimES?: https://github.com/PSI-Rockin/DobieStation/wiki/Making-a-PS2-Emulator:-From-Bits-to-Pixels
07:44:05*arnetheduck joined #nim
07:50:28*cspar_ joined #nim
07:53:44*cspar quit (Ping timeout: 260 seconds)
08:25:47*yglukhov quit (Remote host closed the connection)
08:26:16*yglukhov joined #nim
08:33:57*brainproxy quit (Ping timeout: 240 seconds)
08:37:19*brainproxy joined #nim
08:37:32*jalbo joined #nim
08:39:04*yglukhov quit (Remote host closed the connection)
08:39:37*yglukhov joined #nim
08:43:55*leorize joined #nim
08:43:57*yglukhov quit (Ping timeout: 240 seconds)
08:56:10*jaco60 joined #nim
08:58:15*Vladar joined #nim
09:10:27*brainproxy quit (Ping timeout: 268 seconds)
09:18:00*brainproxy joined #nim
09:23:25FromGitter<mratsim> Can someone run this and tell me if he also get “Illegal Instruction 4” ⏎ ⏎ ```code paste, see link``` ⏎ ⏎ cc @miran [https://gitter.im/nim-lang/Nim?at=5aacde8d2dfcfffd2b2b8d01]
09:24:29*smt quit (Ping timeout: 256 seconds)
09:25:30miranmratsim: i get SIGSEGV
09:26:04planetis[m]what is the correct way to get a correct way to get a port number from a string? most nim programs use parseInt and convrt to uint16 isn't that problematic?
09:26:05planetis[m]maybe add a high parameter to parseSaturatedNatural?
09:26:37FromGitter<mratsim> and if you put the content of the “main” proc out what happens?
09:26:45*brainproxy quit (Ping timeout: 256 seconds)
09:27:19FromGitter<mratsim> @planetis[m], read the code of parseInt/parseUint and customise it for your need
09:27:32miranmratsim: the problem seems to be too big array
09:27:58miranif you change `dz`, `z`, and `timeSteps` to have smaller array, it works fine
09:28:18FromGitter<mratsim> It’s strange because without the main it ran on my computer, I added the main because in a global context not everything is properly optimized and it’s harder to bench
09:29:20FromGitter<mratsim> @miran, this works for me ™ ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5aacdfef012ff2bf681d9b03]
09:29:41miranputting it out of `main`, it is somewhat slower, but let me test it a bit more
09:30:01FromGitter<mratsim> are you using the latest Nim #devel?
09:30:03*jalbo quit (Remote host closed the connection)
09:30:22miranthat's on v0.18 (stable)
09:31:34FromGitter<mratsim> strange, even in non-release mode I get the illegal instruction :/. I’ll file a bug
09:31:38miranok, now i get the strange behaviour
09:31:56miranoutside of `main` it works. inside of it throws SIGSEGV
09:32:30FromGitter<mratsim> which OS are you using” ?
09:33:09miranmanjaro linux
09:33:15FromGitter<mratsim> Ok
09:33:16FromGitter<mratsim> thanks
09:34:24miranit seems like there's some smaller limit for array size when it is inside of `main`
09:37:31FromGitter<mratsim> But it should output “Out of Mem" or “out of stack mem” I think, not illegal instruction.
09:38:16FromGitter<mratsim> The nice to have would be that if the stack memory used is too large for the machine, it throws a compile-time error ;)
09:40:57FromGitter<mratsim> raised: https://github.com/nim-lang/Nim/issues/7349
09:41:03miranbtw, i have implemented a solution which reuses `k` in `eulerSolve` - it is faster and probably lighter on the memory
09:42:08*arecaceae quit (Remote host closed the connection)
09:42:31*arecaceae joined #nim
09:43:47miranand now i have tried to put that version to use `main` - i get 2x speed increase!!
09:47:11FromGitter<mratsim> k can definitely be re-used but still on my machine the code is 3.5 times slower than Python. ⏎ ⏎ I think I have some issue with slicing. mutable slicing returns `var T` but Araq himself told that `var T` return values are hacky
09:49:19miranmratsim: here's the new version: https://play.nim-lang.org/?gist=0c32f68902fde152c78dbb2a0e0552fc
09:50:19FromGitter<mratsim> thanks
09:50:33miranif something feels illogical/unnecessary (i haven't checked) it is because i also have `rk4Solve` in my code which uses those parts
09:50:56*couven92 joined #nim
09:51:07*couven92 quit (Client Quit)
09:51:28miranthanks for reminding me about `main` trick - what a nice free speed-boost!
09:51:31*couven92 joined #nim
09:51:47*couven92 quit (Remote host closed the connection)
09:52:51*couven92 joined #nim
09:53:59*brainproxy joined #nim
09:54:32*Trustable joined #nim
09:56:42FromGitter<mratsim> :), well I’m trying to optimize Arraymancer, not Nim arrays ;)
09:57:35FromGitter<mratsim> I spent a lot of time optimizing matrix multiplication and convolution, “whole tensor operations” but not slicing at all.
10:00:14miranupdate: on some other (longer) examples, i don't get that free boost :(
10:05:28leorizemiran: I think the `main` boost is obsolete long ago. Some examples I find in the forums stop showing any speed improvement.
10:07:29miranleorize: it might be, but on some examples i have just run, there was a noticeable boost!?
10:15:14leorizemiran: cool, I thought it wasn't a thing anymore. Care to share some examples?
10:18:56miranleorize: hmmm, now i cannot reproduce it. this is strange
10:19:41*dddddd joined #nim
10:37:55*SenasOzys joined #nim
10:42:46*miran quit (Quit: Konversation terminated!)
10:47:45*miran joined #nim
11:03:03*Snircle joined #nim
11:23:12*yvjustaguy joined #nim
11:25:16*yvjustaguy quit (Remote host closed the connection)
11:29:38*nsf quit (Quit: WeeChat 2.0.1)
11:36:31*miran quit (Ping timeout: 256 seconds)
11:39:21*SenasOzys quit (Ping timeout: 265 seconds)
11:46:45*SenasOzys joined #nim
11:51:47*PMunch joined #nim
11:53:23PMunchdom96, did you have a look to try out your approach to multiple routing blocks in Jester?
12:04:33*nsf joined #nim
12:24:55*Trustable quit (Remote host closed the connection)
12:32:37*xet7 quit (Quit: Leaving)
12:36:38*leorize quit (Quit: WeeChat 2.0.1)
12:37:23*leorize joined #nim
12:40:48*yglukhov joined #nim
12:45:24*yglukhov quit (Ping timeout: 260 seconds)
12:52:28*dddddd quit (Remote host closed the connection)
12:53:00*sborzamv quit (Client Quit)
12:54:57*Senketsu quit (Ping timeout: 248 seconds)
13:00:34*SenasOzys quit (Ping timeout: 260 seconds)
13:05:25*Senketsu joined #nim
13:12:05*SenasOzys joined #nim
13:13:01*xet7 joined #nim
13:23:34*xet7 quit (Remote host closed the connection)
13:38:55*xet7 joined #nim
13:45:14*leorize quit (Quit: WeeChat 2.0.1)
13:45:44*leorize joined #nim
14:00:23*xet7 quit (Quit: Leaving)
14:02:59*couven92 quit (Ping timeout: 260 seconds)
14:32:59*couven92 joined #nim
14:39:10FromGitter<AjBreidenbach> Is there a reliable way to create a C const in nim?
14:48:44dom96PMunch: not yet
14:53:51*leorize quit (Quit: WeeChat 2.0.1)
14:57:28*xkapastel joined #nim
14:58:02FromGitter<ZarsBranchkin> By the way, what's the situation with game dev with Nim? I don't feel like creating my own framework via SDL and fragworks seems to be pretty dead right now
14:58:42FromGitter<ZarsBranchkin> Also looked at zengine, but couldn't manage to build succesfully for some reason
14:59:11*leorize joined #nim
15:00:42FromGitter<ZarsBranchkin> But so far, frag seemed most appealing. Might as well use it and contribute to it as I go
15:00:53FromGitter<AjBreidenbach> I think frag is dead
15:01:55FromGitter<ZarsBranchkin> I checked zengine and it's last commit was 5
15:02:02FromGitter<ZarsBranchkin> 5 months ago too
15:02:05FromGitter<AjBreidenbach> you can wrap a different game engine
15:02:11FromGitter<AjBreidenbach> written in c or c++
15:02:35FromGitter<AjBreidenbach> should be less error-prone
15:02:40FromGitter<ZarsBranchkin> True, thought about that. I liked polycode, but it's undergoing full rewrite
15:02:50FromGitter<AjBreidenbach> is performance an issue?
15:03:02FromGitter<AjBreidenbach> or is it like a 2d game
15:03:23FromGitter<ZarsBranchkin> Nah, intend on focusing on 2D
15:03:31FromGitter<AjBreidenbach> you could wrap phaser.js
15:04:39FromGitter<Varriount> You might want to talk with @zacharycarter , he's pretty good with game engines
15:05:00FromGitter<AjBreidenbach> isn't he the author of zengine and frag?
15:05:06FromGitter<Varriount> Yes.
15:05:48*BitPuffin joined #nim
15:05:57FromGitter<AjBreidenbach> @ZarsBranchkin you could ask him if he wants to continue zengine
15:23:56*rokups joined #nim
15:24:07*OPQLC5jfred joined #nim
15:25:50FromGitter<zacharycarter> @ZarsBranchkin I'm planning / starting to work on a rewrite of frag
15:26:24dom96Why a rewrite?
15:27:28FromGitter<ZarsBranchkin> Neat, frag looked most exciting from the options
15:30:35*OPQLC5jfred quit (Remote host closed the connection)
15:30:51*nsf quit (Quit: WeeChat 2.0.1)
15:44:37*Trustable joined #nim
15:56:46FromGitter<AjBreidenbach> @zacharycarter I think I still have the tiled parser on my hard drive
15:57:25leorizeHi, I'm writing a wrapper for a C library, and I'm wondering what's the difference between the dynlib pragma and specifying libs in passL. Which one is preferred, and why?
16:07:14FromGitter<AjBreidenbach> isn't passL statically linked?
16:11:19*zahary_ joined #nim
16:11:20dom96dynlib is preferred because Nim prefers dynamic linking
16:11:53FromGitter<AjBreidenbach> why is that? just curious
16:11:54zahary_can you give me an example of a popular API that has an init() function? (something that must be called before using other functions from the API?)
16:11:54dom96also Nim give you the ability to override 'dynlib' (via the `--dynlibOverride` flag) and use --passL to statically link
16:12:10zahary_I need for an example in the manual
16:12:24FromGitter<AjBreidenbach> sdl has init
16:15:22*v00tt846 joined #nim
16:17:22leorizeAjBreidenbach: it's the common usage, you could instruct the linker to link dynamically on *nix system with -l<lib> for example.
16:17:24*v00tt846 quit (Remote host closed the connection)
16:17:44*endragor quit (Remote host closed the connection)
16:18:40*miran joined #nim
16:19:48leorizedom96: sounds like it would be a more flexible approach comparing to feeding passL with pkg-config output. Thanks.
16:20:44dom96what about Windows?
16:26:15FromGitter<mratsim> @zahary_ OpenCL must create some contexts as well but I don’t think it’s popular
16:37:24*endragor joined #nim
16:37:35*nsf joined #nim
16:40:15dom96The reason I ask is because I think {.dynlib.} has the advantage that it is cross-platform
16:41:27*endragor quit (Ping timeout: 240 seconds)
16:43:45leorizedom96: I'm wrapping a Linux-only library, so this should not be an issue. I don't really like the use of dlopen() and the likes, but it appears to be the most portable solution available.
16:51:20*craigger quit (Quit: bye)
16:51:33*craigger joined #nim
16:56:32*yglukhov joined #nim
16:56:51miran!eval echo 2.5 * 3
16:56:54NimBot7.5
16:57:35miranwhy is it in my mind that mixing ints and floats doesn't work? was that the behaviour of some previous nim version? (cc dom96)
16:58:05dom96probably depends on the operator
16:58:23*ieatnerds quit (Quit: Leaving)
17:04:00*yglukhov quit (Remote host closed the connection)
17:07:40*cspar__ joined #nim
17:10:17*cspar_ quit (Ping timeout: 256 seconds)
17:28:28PMunchHmm, I tried to do "nimble install frag". After taking ages to download with no indication it installed a bunch of dependencies and then asked me if I wanted to overwrite a dependency because it already existed and answering no stopped the entire install..
17:33:42PMunchAnswering yes also stops the installation..
17:36:09PMunchdom96, ^
17:39:13*dddddd joined #nim
17:39:37*tefter joined #nim
17:45:39*cspar joined #nim
17:47:35*natrys joined #nim
17:48:21*cspar__ quit (Ping timeout: 265 seconds)
17:53:36*c0ntribut0r joined #nim
18:00:58*tefter quit (Remote host closed the connection)
18:03:49FromGitter<GULPF> @PMunch Mixing still doesn't work. When writing `2.5 * 3` the compiler decides that `3` must be a float. It doesn't work if `3` is stored in a (integer) variable. `let x: float = 1` is also valid. I think this is part of the integer literal magic.
18:04:15PMunchmiran ^
18:04:20PMunchI guess that was really for him
18:04:34FromGitter<GULPF> oh, sorry yes
18:04:59miranthanks GULPF! (and PMunch for mentioning me)
18:06:43*NR18FOseekr joined #nim
18:07:42*c0ntribut0r quit (Quit: Quit)
18:10:02planetis[m]hey asyncfutures documentation is missing
18:13:31*NR18FOseekr quit (Remote host closed the connection)
18:14:06*yglukhov joined #nim
18:17:22*natrys quit (Ping timeout: 246 seconds)
18:17:44*natrys joined #nim
18:22:53*cspar_ joined #nim
18:24:19*cspar quit (Ping timeout: 260 seconds)
18:26:27*natrys quit (Ping timeout: 240 seconds)
18:28:13*natrys joined #nim
18:30:44*yglukhov quit (Remote host closed the connection)
19:03:19*nsf quit (Quit: WeeChat 2.0.1)
19:05:08thor77hm, i kind of enjoy writing nim but i'm sometimes i'm still rly confused by it's style of not embracing/supporting object-orientated programs
19:05:33thor77but that's probably because i'm mostly porting some scripts i wrote in python
19:05:57thor77and i'm really used to that structure from most languages i used for extended periods so far
19:10:54*federico3 joined #nim
19:17:52FromGitter<mratsim> just use `proc foo(o: MyAwesomeObject): Foo = …`, behind the scene it’s different but while using it it’s the same
19:19:14*yglukhov joined #nim
19:20:40*couven92 quit (Read error: Connection reset by peer)
19:22:54miranhey mratsim! i modified a bit euler benchmarks, all versions are now faster
19:24:52thor77mratsim: yeah, i sometimes do. it still feels weird defining methods outside of an object body
19:26:51FromGitter<AjBreidenbach> how do you index a pointer to an array?
19:27:41FromGitter<AjBreidenbach> if I've got like a `ptr Foo`
19:33:59Araquse ptr UncheckedArray[Foo]
19:36:28FromGitter<AjBreidenbach> that did it, thanks
19:36:55GitDisc<treeform> I wrote some examples and fixed some bugs with the the Cairo package: https://github.com/treeform/cairo
19:37:08GitDisc<treeform> Thoughts? Suggestions? Feedback?
19:39:57GitDisc<treeform> There is on official https://github.com/nim-lang/cairo package made by Araq, which did not work for me, then there is https://github.com/ngtk3/nim-cairo which did work but had some bugs, I based my work on it.
19:41:00GitDisc<treeform> There was also this: https://news.ycombinator.com/item?id=16535525
19:41:54mirantreeform: very nice to see so much examples, containing both code and the result!
19:42:27thor77yeah, i like that, too :)
19:42:46GitDisc<treeform> thanks, I ported the C examples they had on their page
19:42:48GitDisc<treeform> Good examples help with writing stuff also a good example of what the library can do.
19:44:56miranthere are so many projects missing that part, and i don't have enough time/motivation to go through that myself just to see what is the project about
19:45:58*natrys quit (Ping timeout: 264 seconds)
19:47:39*natrys joined #nim
19:48:22*kunev quit (Ping timeout: 264 seconds)
19:48:51*yglukhov quit (Remote host closed the connection)
19:48:55*salewski joined #nim
19:49:26*kunev joined #nim
19:49:48salewskitreeform, I really suggest using oldgtk3 instead of ngtk3.
19:50:25salewskiI will really delete ngtk3 soon, as I wrote multiple times already.
19:51:05salewskiAnd when you like cairo, it would be great if you could test cairo from gintro.
19:51:26salewskiUnfortunately I have no time for testing.
19:52:12salewskiThe special fact about cairo from gintro is, that it was not well supported by gobject-introspection,
19:52:21*scivolaCC14XY joined #nim
19:52:38salewskiso it is different from the other gintro modules.
19:53:38*scivolaCC14XY quit (Remote host closed the connection)
19:53:46*isghetto joined #nim
19:54:46*isghetto quit (Remote host closed the connection)
19:56:18*salewski quit (Quit: WeeChat 1.9.1)
20:01:00GitDisc<treeform> salewski are you ngtk3 ?
20:02:11GitDisc<treeform> you want me to test this: https://github.com/StefanSalewski/gintro/blob/master/gintro/cairo.nim
20:02:47GitDisc<treeform> I am mainly interested in Cairo not GTK
20:02:53*MJCaley quit (Quit: MJCaley)
20:06:16*nsf joined #nim
20:07:04*salewski joined #nim
20:07:35salewskitreeform, no I am still salewski. but once I wrote ngtk3.
20:08:28salewskiMost peole asked for a nimble install, so I converted ngtk3 single files to oldgtk3 nimble package.
20:09:12salewskiand oldgtk3 is for latest gtk3, while ngtk3 files are a bit older.
20:09:49salewskiI do not maintain ngtk3 any more, it really is deprecated now.
20:10:26salewskiAnd for cairo from gintro, that one is high level, so it should be more fun to use.
20:10:38GitDisc<treeform> Error: undeclared field: 'ARGB32'
20:10:51GitDisc<treeform> It seems like the gintro's cairo does not have all symbols
20:11:06salewskiBut there may be bugs.
20:11:28salewskiThat can be true, I have to investigate that.
20:11:47GitDisc<treeform> https://github.com/treeform/cairo/blob/master/src/cairo.nim#L104
20:11:51salewskiWould be great if you could create an issue for gintro issue tracker.
20:12:11GitDisc<treeform> you made it lower case in yours
20:12:17GitDisc<treeform> argb32
20:14:08GitDisc<treeform> serface.create() does not seem to work
20:14:10salewskiYes indeed, as it is enum, which should be lover case. As most peole demand.
20:14:15GitDisc<treeform> proc create(T: typedesc; size = 1.Positive): ptr T:type
20:14:26GitDisc<treeform> hmm
20:14:35salewskiIf it is upper case in other modules, then it is c2nim legacy.
20:16:15GitDisc<treeform> i think you named that newContext
20:16:41salewskiSorry, can not see proc create( in my gintro cairo version.
20:17:29GitDisc<treeform> ok I ported my first example to work with your gintro's cairo
20:17:40salewskiGreat!
20:17:44GitDisc<treeform> Is gintro's cairo better in everyway?
20:18:19GitDisc<treeform> I run into bugs with the old wrapper, around dashed lines and matrixes
20:18:38GitDisc<treeform> dashed lines are pointers to array
20:18:41salewskiIt will be better if people test and support it. It is high level, finalizer support and all that.
20:18:51salewskiThat is what most peole want.
20:18:52GitDisc<treeform> and it needed pointers to matrixes
20:19:08GitDisc<treeform> basically there were pointer confusions
20:20:15GitDisc<treeform> what do you mean, it would segfault?
20:20:37salewskiYes there may be bugs, in old and new cairo. I did not have to test and investigate all that myself.
20:20:44GitDisc<treeform> bugs I found was functions taking a float, when it needed to be a pointer to float array
20:21:47salewskiWould be great if you could create github issues, maybe with suggested fixes.
20:22:07salewskiI have not much spare time currently, but I will try to fix it.
20:22:27GitDisc<treeform> should cairo be its own module?
20:23:17GitDisc<treeform> I want to use cairo for game UI (render to texture) and for producing offline graphs as PNGs
20:23:24GitDisc<treeform> I don't want GTK stack
20:23:51salewskicairo is a separate module, with some support modules like pango-cairo. But it is all bundled in gintro. That is what most peole desired.
20:24:24FromGitter<AjBreidenbach> is there a way to get sizeof to not cause a segfault?
20:25:08salewskiCairo from gintro does not depend on gtk, it is just a fact that when you install gintro you get all the modules.
20:25:54salewskiYou can ignore the rest. Otr you may modily gen.nim generator script so that it installs only cairo.
20:26:19GitDisc<treeform> what if you make gintro depend on cairo
20:26:26GitDisc<treeform> then people can install cairo or just gintro ?
20:27:48salewskiYes, I may do that. But it may confuse peole, because then we have really many different cairo modules.
20:30:35GitDisc<treeform> well there is already Araq's main one?
20:30:42GitDisc<treeform> which is really really old
20:31:19salewskiBut he will not drop his cairo.
20:32:30GitDisc<treeform> Why not?
20:32:34GitDisc<treeform> ```Error: unhandled exception: cairo_surface_get_reference_count(surface.impl) == h [AssertionError]
20:32:34GitDisc<treeform> Error: execution of an external program failed: 'C:\Users\me\Dropbox\p\cairo\examples\clip_image.exe '```
20:32:38salewskiAnd when I separate cairo from gintro, I may do that also for pango or glib, as these can be used separeately too.
20:32:48GitDisc<treeform> I get this error.
20:33:41GitDisc<treeform> ``` #assert(cairo_surface_get_reference_count(surface.impl) == h) # is our guess OK?``` If I comment out the assert it works.
20:33:46GitDisc<treeform> Do you know why its there?
20:34:08GitDisc<treeform> ```
20:34:08GitDisc<treeform> proc setSourceSurface*(cr: Context; surface: Surface; x, y: float) =
20:34:08GitDisc<treeform> #GC_ref(source) # we guess that surface is nor referenced, but a new intern pattern is created
20:34:09GitDisc<treeform> let h = cairo_surface_get_reference_count(surface.impl)
20:34:09GitDisc<treeform> cairo_set_source_surface(cr.impl, surface.impl, x.cdouble, y.cdouble)
20:34:11GitDisc<treeform> #assert(cairo_surface_get_reference_count(surface.impl) == h) # is our guess OK?```
20:35:08salewskiSorry, can not remember.
20:35:33*boklm417 joined #nim
20:35:47salewskiAs I told you, cairo from gintro is a bit defferent as all the other gtk gintro modules.
20:36:09salewskiIt was not really supported by gobject introspection.
20:36:50salewskiI tried hard to write it correct -- and I will correct all the reported issues from github.
20:36:54GitDisc<treeform> ok, I am not sure what that means.
20:38:08salewskiAll the other gtk3 modules from gintro are generated from and xml database using gobject-introspection API.
20:38:45salewskiBut cairo was not really supported by that, so I tried to write it mannually in the same way.
20:39:35salewskiThe process took more than 100 hours, so there was not much spare time for testing.
20:39:39*boklm417 quit (Remote host closed the connection)
20:41:16salewskiAll that depends on the number of users -- when I see that people use it, I will continue my work.
20:42:12salewskiFor gtk3 itself we have at least one smart user, called cdlrs or similar, who has reported and fixed a few issues already.
20:42:49salewskiFor cairo you seem to be the first and single user. I will remember you and continue work when I have time.
20:42:59salewskiHave to leave now, bye.
20:43:26*salewski quit (Quit: WeeChat 1.9.1)
20:51:18GitDisc<treeform> bye, thank you for your hard work!
20:59:40FromGitter<AjBreidenbach> is there a way to get sizeof to not cause a segfault?
21:05:07*rockcavera quit (Remote host closed the connection)
21:05:48*xet7 joined #nim
21:11:19*smt joined #nim
21:25:55FromGitter<Varriount> !eval echo sizeof(int)
21:25:57NimBot8
21:26:10FromGitter<Varriount> @AjBreidenbach ^
21:26:28*rokups quit (Quit: Connection closed for inactivity)
21:27:21*natrys quit (Ping timeout: 264 seconds)
21:27:43*natrys joined #nim
21:29:31FromGitter<AjBreidenbach> `T1_[0] = nimIntToStr(((NI)sizeof(napi_property_descriptor)));`
21:29:43FromGitter<AjBreidenbach> this line causes a segfault and I can't figure out why
21:30:44*nsf quit (Quit: WeeChat 2.0.1)
21:31:46FromGitter<AjBreidenbach> @Varriount
21:35:52FromGitter<AjBreidenbach> so does this `asgnRefNoCycle((void**) (&(*T1_).descriptors), newSeq_wnW5dy7crYEXJKafgLF0sw(((NI) 0)));`
21:36:37FromGitter<AjBreidenbach> `sizeof(napi_property_descriptor)` evaluates to 64
21:36:46FromGitter<AjBreidenbach> in both C and Nim
21:42:21FromGitter<mratsim> @miran, try to also compile with OpenMP. Also link your Python Numpy with MKL if you can, on the Python benchmark it made EulerSolve 3x faster
21:44:25miranmratsim: i don't have mkl version. i've seen your results - my new version should be a bit faster both with mkl and without
21:45:02miranmost of speed improvements are in nim's native array version
21:45:52FromGitter<mratsim> okay, I’m trying OpenMP and it actually slows down Eurler solve due to false sharing
21:50:48miranbtw, now native array version can be put in `main` function, but it makes no difference speed-wise
21:52:06mirando you want me to submit that version, so it is similar to tensor one?
21:54:45FromGitter<mratsim> yes please do
21:58:56mirandone
22:01:14FromGitter<Varriount> @AjBreidenbach If you use "--linedir: on" when compiling your program, you can see the lines of Nim code that the C code maps to.
22:03:58*natrys quit (Ping timeout: 264 seconds)
22:04:21FromGitter<AjBreidenbach> `newSeqint ()` should not cause a segfault probably?
22:04:26*btbytes joined #nim
22:04:50*btbytes quit (Client Quit)
22:05:00FromGitter<AjBreidenbach> I think I have bigger problems
22:06:43*yglukhov joined #nim
22:10:57*yglukhov quit (Ping timeout: 240 seconds)
22:16:22*jaco60 quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
22:25:43dom96AjBreidenbach: do you have code you can share which reproduces the problem?
22:29:34FromGitter<AjBreidenbach> I feel like I'm linking it wrong or something
22:32:10*miran quit (Quit: Konversation terminated!)
22:34:18*FromGitter quit (Remote host closed the connection)
22:34:18*oprypin quit (Quit: Bye)
23:05:40*Vladar quit (Quit: Leaving)
23:08:46*Trustable quit (Remote host closed the connection)
23:18:47*endragor joined #nim
23:23:46*endragor quit (Ping timeout: 264 seconds)
23:24:28*FromGitter joined #nim
23:24:32*BlaXpirit joined #nim
23:24:54*BlaXpirit is now known as oprypin
23:32:58*arthurz joined #nim
23:33:14*arthurz quit (Client Quit)
23:33:45*arthurz joined #nim