<< 12-07-2020 >>
00:00:02*junland quit (Quit: %ZNC Disconnected%)
00:00:44FromDiscord<impbox> hmm the bitops module says it's compatible with JS backend, however when I try to use it on the js backend I get the following error: `\lib\pure\bitops.nim(70, 39) Error: cannot evaluate 'sizeof' because its type is not defined completely`, works fine on c backend
00:01:43*junland joined #nim
00:02:02*couven92 joined #nim
00:02:20FromDiscord<Recruit_main707> (About nimue): its pretty clean ngl, and considering it’s basically OOP I guess it’s not that bad it looks like OOP
00:03:20FromDiscord<Elegant Beef> Also recruit did you see what my end result was for storing/recovering types from a stream was?
00:03:54FromDiscord<Recruit_main707> I think I didn’t
00:03:56FromDiscord<Elegant Beef> Basically any type that's a non pointer can be written to a string stream, with the `write` prock
00:03:59*couven92 quit (Remote host closed the connection)
00:04:04FromDiscord<Elegant Beef> Or if it includes a pointer it cant
00:04:22FromDiscord<Elegant Beef> so you can make any type that relies only on primitives, and you can parse to/from a byte stream using a string stream
00:04:31FromDiscord<Elegant Beef> So strings are out of the question
00:04:42*couven92 joined #nim
00:05:04FromDiscord<Recruit_main707> That’s nice, have you considered doing some benchmarks against Jasón and msgpack?
00:05:22FromDiscord<Recruit_main707> json*
00:05:30FromDiscord<Elegant Beef> If you use `stringStream.write` it writes all the primitive data and then the pointer to the data
00:05:32*Shucks quit (Quit: Leaving)
00:05:54FromDiscord<Elegant Beef> So if we can figure out how to get the data instead of the pointer we can either update the stream.write proc for generics or make our own
00:06:08FromDiscord<Elegant Beef> Well it's going to be faster than Json but idk by how much
00:07:34FromDiscord<Recruit_main707> I might try it out of curiosity with msgpack tomorrow
00:07:36FromDiscord<Elegant Beef> It's a binary file after all
00:11:14*couven92 quit (Remote host closed the connection)
00:11:44*couven92 joined #nim
00:13:16*couven92 quit (Remote host closed the connection)
00:13:44*couven92 joined #nim
00:19:47skrylar[m]bleh. should get around to finishing the gtk3 module
00:19:51skrylar[m]it was almost done iirc
00:20:28*endragor joined #nim
00:25:25*endragor quit (Ping timeout: 264 seconds)
00:26:25FromDiscord<Elegant Beef> How would one get the underlying type of a sequence
00:26:33FromDiscord<Elegant Beef> or any generic for that matter 😄
00:26:48FromDiscord<impbox> T?
00:27:01FromDiscord<Elegant Beef> yea i mean `@[10]` i want to get int somehow from that
00:27:36FromDiscord<Elegant Beef> well more accurately `var a:seq[int]`
00:28:01FromDiscord<impbox> https://play.nim-lang.org/#ix=2rqe
00:28:27FromDiscord<Elegant Beef> Thanks
00:28:45FromDiscord<impbox> there may be other easier ways but that's what came to mind
00:29:03FromDiscord<exelotl> oh lol, that's good
00:29:10FromDiscord<exelotl> I was about to delve into macros xD
00:29:31FromDiscord<Elegant Beef> Lol im daft
00:29:52FromDiscord<Elegant Beef> Yes im daft
00:30:19FromDiscord<exelotl> [backing vocals] *he's daft*
00:30:24FromDiscord<impbox> `echo $typeof(a[0])`
00:30:36FromDiscord<Elegant Beef> Yea doesnt work when the seq is empty impbox
00:30:43FromDiscord<impbox> it does =)
00:30:50FromDiscord<Elegant Beef> No the latest
00:30:54FromDiscord<impbox> i wasn't sure it would
00:31:09FromDiscord<Elegant Beef> `a[0]` should error if emptied
00:31:14FromDiscord<impbox> https://play.nim-lang.org/#ix=2rqh
00:31:15FromDiscord<impbox> try it
00:31:30FromDiscord<Elegant Beef> The fuck D:
00:31:46FromDiscord<impbox> typeof isn't actually accessing the sequence contents
00:32:06FromDiscord<impbox> you could do a[1000] it's the same
00:32:59FromDiscord<impbox> ok, back to gamedev
00:45:32FromDiscord<Rika> does anyone use nim-serialization (making formats, not just using json_serialization)
00:47:27FromDiscord<Rika> i'd like to know your opinion on it
00:47:43FromDiscord<Rika> is it hard to use, better than implementing your own api, etc
00:56:27*endragor joined #nim
01:00:34*endragor quit (Ping timeout: 240 seconds)
01:24:03FromDiscord<Elegant Beef> @Recruit_main707 silly progress↵https://play.nim-lang.org/#ix=2rqp
01:24:43FromDiscord<Elegant Beef> using 4 null characters is clearly dumb for seperating elements
01:24:57FromDiscord<Elegant Beef> clearly should just use 4 bytes to indicate the count of them
01:25:30FromDiscord<Rika> or the charlen of them
01:25:47FromDiscord<Elegant Beef> Yea i mean both are the same
01:26:53FromDiscord<Elegant Beef> idk isnt 2^16 enough elements? 😄
01:28:32FromDiscord<Elegant Beef> But hey i got around the dumb pointer issue
01:28:46FromDiscord<Rika> congrats
01:28:49*endragor joined #nim
01:28:51FromDiscord<Rika> the code is now 5x larger
01:28:56FromDiscord<Elegant Beef> But i know atm recursive collection is dumb
01:28:58FromDiscord<Elegant Beef> Lol
01:29:11FromDiscord<Elegant Beef> it will shrink when i store count instead
01:30:25FromDiscord<Elegant Beef> Well a tad bit
01:33:25*endragor quit (Ping timeout: 258 seconds)
01:35:04*chemist69 quit (Ping timeout: 256 seconds)
01:37:02*chemist69 joined #nim
01:40:28*couven92 quit (Ping timeout: 256 seconds)
01:45:42FromDiscord<Elegant Beef> Now with nested objects↵https://play.nim-lang.org/#ix=2rqv
01:46:45disruptekif you can do better than frosty, please do so. the trick is in writing variant objects.
01:48:56*arecaceae quit (Remote host closed the connection)
01:49:21*arecaceae joined #nim
01:51:42shashlickDisruptek - testing nimgit2 with prebuilt binaries upto 1.0.1
01:52:46shashlickMade a bunch of custom builds with jbb - https://bintray.com/genotrance/binaries/LibGit2
01:55:15disruptekdoes it work?
01:56:13shashlickTesting in progress
02:00:26*laqq3 joined #nim
02:01:31*endragor joined #nim
02:05:47shashlickdisruptek: for some reason, gittyup is failing - makes no sense - https://travis-ci.org/github/genotrance/travister/jobs/707258741#L11004
02:06:22shashlickhere's the test script - https://github.com/genotrance/travister/blob/master/test.sh
02:09:03shashlicki don't see why nimterop and nimgit2 get installed again after they are already installed earlier
02:10:51shashlickanyway, shouldn't gate the release - i think the problem is that nimterop is nimble develop mode so it is treated as #head so since you have nimterop < 1.0.0, it might be excluding head and installing v0.6.2 as well
02:11:35disruptekhttps://vale.dev/
02:14:46disruptekshashlick: i cannot load the raw log for that job.
02:17:48*endragor quit (Ping timeout: 256 seconds)
02:21:20FromDiscord<Elegant Beef> Ok object variants are going to be hard to save
02:24:35disrupteki think timmy solved it recently, but also there's json.to for inspiration.
02:24:55*muffindrake quit (Ping timeout: 272 seconds)
02:26:25*muffindrake joined #nim
02:29:26bungdoes karax deep diff Component's fields ?
02:35:49shashlickNever mind
02:44:20FromDiscord<Yardanico> guess what that is guys? 😄 https://media.discordapp.net/attachments/371759389889003532/731702453795553340/unknown.png
02:44:36FromDiscord<Yardanico> apparently some person updated Sciter bindings for Nim a bit (although for win only), and with a couple of fixes I launched it on linux
02:44:36FromDiscord<Yardanico> https://github.com/citrusn/nsciter
02:44:44FromDiscord<Yardanico> (Sciter as in https://sciter.com/)
02:45:19FromDiscord<Elegant Beef> So it's a webview
02:45:23disruptekbut those window decorations...
02:45:35FromDiscord<Yardanico> @Elegant Beef not exactly
02:45:47FromDiscord<Yardanico> Sciter implements custom html/css/scripting engines from ground up
02:45:59FromDiscord<Yardanico> even though the HTML is fully compatible with normal HTML
02:46:02FromDiscord<Yardanico> the library itself is 5-8mb
02:46:10FromDiscord<Yardanico> @disruptek it's from my current DE, not the framework
02:46:17FromDiscord<Elegant Beef> I'd hope 😄
02:46:17disrupteki know, it's horribad.
02:46:26FromDiscord<Yardanico> and yes, sciter is not about native GUI and the source is closed (unless you pay)
02:46:29FromDiscord<Yardanico> well this is just a temporary DE
02:46:31FromDiscord<Elegant Beef> what is that XFCE ugly 😄
02:48:18FromDiscord<Yardanico> also apparently the bindings work because the sciter API was completely unchanged even since the old commit which was made 4 years ago in the repo
02:48:23FromDiscord<Yardanico> even after one major version increase
02:48:28FromDiscord<Elegant Beef> Damn
02:48:35FromDiscord<Yardanico> well, the C API that is
02:48:46FromDiscord<Yardanico> HTML/CSS/scripting engines of course received fixes, also new features and stuff
02:48:49FromDiscord<Yardanico> but it still fits with the same API
02:49:03FromDiscord<Elegant Beef> is the scripting js or a proprietary language?
02:49:10disruptekproprietary.
02:49:22FromDiscord<Yardanico> it's similar to JavaScript in some ways, but it's not JS
02:49:36FromDiscord<Yardanico> also sciter's creator was a part of W3C HTML5 development group btw
02:49:44FromDiscord<Yardanico> since Sciter had a lot of features modern HTML5/CSS have years before
02:50:02FromDiscord<Yardanico> @Elegant Beef https://sciter.com/developers/for-web-programmers/tiscript-vs-javascript/
02:50:19FromDiscord<Yardanico> if you want you can not use any of this scripint language aAT ALL
02:50:22FromDiscord<Yardanico> (edit) 'aAT' => 'AT'
02:50:24FromDiscord<Yardanico> and only native APIs
02:50:28FromDiscord<Yardanico> but sometimes it's more convenient
02:50:28FromDiscord<Elegant Beef> Ah
02:50:34FromDiscord<Elegant Beef> But i mean this is a JIT language
02:50:38FromDiscord<Yardanico> no?
02:50:43FromDiscord<Yardanico> it's a VM'd language
02:50:49FromDiscord<Elegant Beef> > compiler that produces byte code
02:50:52FromDiscord<Elegant Beef> Sounded like JIT
02:50:56FromDiscord<Yardanico> that's not JIT
02:51:08FromDiscord<Yardanico> JIT is what makes native machine code on-the-fly from the bytecode
02:51:16FromDiscord<Elegant Beef> C#/JVM both take bytecode into their VMs
02:51:20FromDiscord<Yardanico> yes
02:51:25FromDiscord<Yardanico> but they *also* have JIT
02:51:28FromDiscord<Elegant Beef> Ah
02:51:31FromDiscord<Yardanico> you don't need JIT if you have a VM
02:51:43FromDiscord<Yardanico> I mean it's not required
02:51:50FromDiscord<Elegant Beef> Thought the VM used said byte code
02:52:11FromDiscord<Yardanico> well byte code literally means "bytecode"
02:52:13FromDiscord<Yardanico> not machine code
02:52:14FromDiscord<Yardanico> 😛
02:52:16FromDiscord<Elegant Beef> Yea
02:52:20FromDiscord<Elegant Beef> Isnt that where the JIT happens
02:52:23FromDiscord<Elegant Beef> at the VM
02:52:26FromDiscord<Yardanico> no, later
02:52:42FromDiscord<Yardanico> because compiling all byte-code to JIT can be costly or even make the program less efficient
02:52:52FromDiscord<Yardanico> so JITs usually only compile the most executed parts of the running code
02:54:18*endragor joined #nim
02:54:49*pangey quit (Ping timeout: 264 seconds)
02:55:31FromDiscord<Elegant Beef> Ah i see, a VM is just an intepreter 😄
02:55:47FromDiscord<Elegant Beef> And unlike python they convert to bytecode for their intepreter
02:55:59FromDiscord<Yardanico> well bytecode is useful for mainly one reason
02:56:09FromDiscord<Yardanico> the fact that after you parse source into bytecode, you don't need to parse byte-code again
02:56:12FromDiscord<Yardanico> less time to start the execution
02:56:17FromDiscord<Elegant Beef> Yea i got that
02:56:21FromDiscord<Yardanico> that's why most distros precompile .py files into .pyc
02:56:26FromDiscord<Yardanico> so they don't get parsed each time
02:57:02*pangey joined #nim
02:59:49FromDiscord<Yardanico> anyway even if sciter is proprietary, they're pretty cool about licensing
03:00:06FromDiscord<Yardanico> basically "use any files you find in sciter-sdk, just include a reference to us"
03:00:46FromDiscord<Yardanico> they provide binaries (sciter as a dynamic library or as a standalone app for small html/css/tiscript only projects) for windows/linux (arm32 and amd64)/macos
03:00:56FromDiscord<Rika> python uses bytecode
03:01:19disruptekrika: watch yourself.
03:02:01shashlickDo you need nimterop bindings
03:02:18shashlickSeems like there's a need for up to date bindings for these gui libs
03:02:29FromDiscord<Yardanico> for sciter? maybe I should do, but these bindings work already, although they're a bit of a mess
03:02:34FromDiscord<Yardanico> basically the API itself didn't change at all
03:02:43FromDiscord<Yardanico> so these bindigs (from a fork I'm using) mostly work
03:02:50FromDiscord<Yardanico> I'm not sure if nimterop will work with scinter's headers
03:03:09shashlickIt looked like simple c
03:03:09disruptekthat sounds like a challenge.
03:03:21shashlickI'm too old for those
03:03:25FromDiscord<Rika> $ watch ./rika
03:03:34FromDiscord<Yardanico> @shashlick one sec
03:03:49FromDiscord<Yardanico> they're in here https://github.com/c-smile/sciter-sdk/tree/master/include
03:03:54FromDiscord<Yardanico> we only need .h files obviously 🙂
03:04:10FromDiscord<Yardanico> it's just that it has a lot of defines
03:04:15FromDiscord<Yardanico> and checking them
03:04:38FromDiscord<Yardanico> well I guess nimterop will just solve them before generating the binding and I'll get bindings for linux only
03:06:52*endragor quit (Ping timeout: 256 seconds)
03:07:38shashlickcloning - why is it such a fat repo
03:07:58FromDiscord<Yardanico> because it has binaries : )
03:08:08FromDiscord<Yardanico> all publicly available versions of sciter
03:08:15FromDiscord<Yardanico> and of course they're all in history
03:08:19FromDiscord<Yardanico> so you better do a shallow clone 😄
03:09:13shashlickokay depth = 1
03:09:36FromDiscord<Rika> mmmm binaries in a git repo
03:09:59FromDiscord<Yardanico> well why not, in that case it's actually a bit useful 😛
03:10:04FromDiscord<Yardanico> since you have the whole history in case you want to rollback
03:10:06FromDiscord<Yardanico> and free CDN
03:10:43shashlickgitnim
03:10:49shashlickgtk2 or 3
03:10:53FromDiscord<Yardanico> gtk3
03:10:57FromDiscord<Yardanico> x64 only
03:11:03FromDiscord<Yardanico> well, also arm32
03:11:11shashlickgreat - it will pull in all of gtk in the wrapper
03:11:25FromDiscord<Yardanico> well but why?
03:11:40FromDiscord<Yardanico> you can't statically link with it anyway, they only provide public api for their dynamic library
03:11:55FromDiscord<Yardanico> static linking is only if you buy a license (then you'll get source code)
03:12:11FromDiscord<Yardanico> well I mean it still can be useful, but they use native APIs on windows for example
03:12:13FromDiscord<Yardanico> and on macos
03:12:24FromDiscord<Yardanico> They use GTK on Linux because that's arguably the most "native" gui toolkit on it
03:13:41shashlickwell, nimterop recurses into #include files so need to turn that off
03:13:46shashlickand do each header specifically
03:14:35FromDiscord<Yardanico> yeah, the "bindings" seem to have used c2nim
03:14:49FromDiscord<Yardanico> official ones*
03:17:11shashlickthis is like a gtk wrapper action replay
03:17:16shashlickdid that a week ago so should be quick
03:18:12FromDiscord<Yardanico> i hope so, then it'll be much easier to create higher-level scinter bindings 😛
03:18:39FromDiscord<Yardanico> although scinter itself isn't "popular", it seems to be successfully used in commercial apps
03:18:48FromDiscord<Yardanico> a lot of antiviruses specifically use it for their UI
03:19:25shashlickthat's not a great advertisement
03:19:32FromDiscord<Yardanico> 😄
03:19:49FromDiscord<Yardanico> well they have a list of their customers on the website
03:20:04FromDiscord<Yardanico> also War Thunder's launcher uses sciter too apparently
03:20:13FromDiscord<Yardanico> (it's a game)
03:20:23shashlickwe need all the .h files covered right?
03:20:46FromDiscord<Yardanico> well I'm not sure if 100% all
03:20:54FromDiscord<Yardanico> I think sciter-x-***.h ones for sure
03:21:46FromDiscord<Yardanico> oh wait maybe I'm really wrong
03:22:25FromDiscord<Yardanico> well the x-api.h yes for sure
03:23:10FromDiscord<Yardanico> same for sciter-[x-behavior, x-def, x-dom, x-graphics, x-request,x-types,x-value]
03:23:42FromDiscord<Yardanico> basically you can see here which ones it includes for all, and which ones only for C++ - https://github.com/c-smile/sciter-sdk/blob/master/include/sciter-x.h#L24
03:26:35*laqq3 quit (Ping timeout: 256 seconds)
03:27:25*NimBot joined #nim
03:27:38FromDiscord<Yardanico> so in the end you'll have a huge ISciterAPI type
03:27:53FromDiscord<Zachary Carter> How can I deal with - ```span<const int16_t>``` with importcpp?
03:28:07FromDiscord<Zachary Carter> I tried span[int16] but I get an error
03:28:22FromDiscord<Zachary Carter> `no viable conversion from 'span<const int16_t>' to 'span<NI16>'`
03:29:52FromDiscord<Zachary Carter> oh I can just importcpp `const int16_t` as a type cool
03:41:57FromDiscord<Yardanico> well even sciter's low-level binding is "easy" when you don't have to interface with your native app at all 😄 https://media.discordapp.net/attachments/371759389889003532/731716953621790770/unknown.png
03:44:15FromDiscord<Zachary Carter> nice
03:44:15*endragor joined #nim
03:48:11FromDiscord<Yardanico> @shashlick also - you don't really need to provide it as "dynlib" for the whole thing
03:48:48FromDiscord<Yardanico> the current binding basically loads the DLL and _only_ gets a single proc called SciterAPI which returns an instance of that interface (which contains pointers to all functions of the API)
03:49:49FromDiscord<Yardanico> very interesting solution 😛
03:50:44*endragor quit (Remote host closed the connection)
03:50:58*endragor joined #nim
03:51:06FromDiscord<Yardanico> (I mean that's how the library works)
03:58:32FromDiscord<Zed> has anyone tried julia out for ml?
04:04:17*njoseph quit (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.)
04:04:23*njoseph joined #nim
04:04:24shashlickwhat specific portions do you need
04:06:02*supakeen quit (Quit: WeeChat 2.8)
04:06:41*supakeen joined #nim
04:06:57FromDiscord<Elegant Beef> I feel dirty calling this recursively↵https://play.nim-lang.org/#ix=2rqO
04:07:19FromDiscord<Elegant Beef> lol at line 38..41
04:09:18shashlickYardanico - c++ mixed up with C
04:17:40FromDiscord<Yardanico> @shashlick we only need the pure C part 🙂
04:17:48FromDiscord<Yardanico> they mix C++ in to provide some convenience wrappers for it
04:20:58*hoijui joined #nim
04:21:13FromDiscord<Yardanico> idk if it's easy to do with nimterop, I also never tried with c2nim myself, just used someone else's bindings
04:22:09shashlickthere was one portion which is incorrectly c++
04:23:00shashlickwas trying to use the cfg file method but i need some cOverrides
05:02:14bunghttps://github.com/bung87/nimvideo/blob/master/src/nimvideo/header.nim#L19 why it does not redraw the view?
05:03:43*arecaceae quit (Remote host closed the connection)
05:04:27*arecaceae joined #nim
05:08:10ForumUpdaterBotNew thread by Bung: Karax not redraw when seq data changed, I called autoRef.markDirty() and redraw(), see https://forum.nim-lang.org/t/6537
05:11:22shashlick@Yardanico - here's what i have so far - http://ix.io/2rqU - still some missing types that need to be imported from gtk, etc.
05:11:38FromDiscord<Yardanico> oh nice
05:11:57FromDiscord<Yardanico> how do you import locally like that?
05:16:04FromDiscord<Yardanico> also would it be possible to make it cross-platform later? for cross-compilation and such
05:16:28FromDiscord<Yardanico> but yeah, I'll try it 😛
05:22:01FromDiscord<Yardanico> I'm getting some errors though, one from missing hb.h (added harfbuzz cIncludeDir)
05:22:02*Tongir quit (Remote host closed the connection)
05:22:20FromDiscord<Yardanico> and now "ERROR: cstring: No such file or directory", I'm on Artix (Arch fork)
05:22:25*Tongir joined #nim
05:22:31FromDiscord<Yardanico> "cstring" seems to come from C++ stdlib
05:23:53FromDiscord<Yardanico> ah well I solved it I think
05:23:58FromDiscord<Yardanico> " Error: undeclared identifier: 'LPRECT'" 😛
05:24:04FromDiscord<Yardanico> but it is as you say now
05:24:58FromDiscord<Yardanico> LPRECT can be redefined in Nim side, I'll try
05:25:16FromDiscord<Yardanico> with cOverride
05:28:26FromDiscord<Yardanico> @shashlick I think nimterop is parsing sciter-x-graphics (SciterGraphicsApi struct) incorrectly
05:29:38FromDiscord<Yardanico> ISciterAPI too
05:30:04FromDiscord<Yardanico> it names all fields with "SCFN"
05:30:10FromDiscord<Yardanico> and assumes argument type to be the proc name
05:30:19FromDiscord<Yardanico> (yeah these includes use some macros and stuff)
05:31:16FromDiscord<Yardanico> seems to be same for SciterRequestAPI
05:38:28FromDiscord<Yardanico> my src is https://play.nim-lang.org/#ix=2rqX
05:38:45shashlickGotta bed but will take a look tomorrow
05:38:55FromDiscord<Yardanico> it's okay, I'm going to sleep soon to, thanks for all the work 🙂
05:39:29shashlickYa you need to comment out cstring in that one file om.h
05:39:45FromDiscord<Yardanico> yeah I made it empty 😛
05:39:57shashlickGotta define some gtk imports in cOverride
05:40:16FromDiscord<Yardanico> I mean it won't work properly because main interface structs are getting parsed incorrectly
05:40:36FromDiscord<Yardanico> check ISciterAPI for example in the generated .nim file
05:41:48shashlickWill check tomorrow
05:42:10shashlickFor now you can cOverride any bugs and we can fix in nimterop
05:42:27*debased joined #nim
05:44:59shashlickCan you snippet the bad portion
05:46:13FromDiscord<Yardanico> Sorry, I'm already away from the PC, but it's basically from this C code - e.g https://github.com/c-smile/sciter-sdk/blob/master/include/sciter-x-api.h#L54
05:46:31FromDiscord<Yardanico> It's supposed to call a SCFN macro but nimterop makes a field named SCFN
05:46:43FromDiscord<Yardanico> And first argument being the actual function name
05:47:31FromDiscord<Yardanico> SCFN is defined in https://github.com/c-smile/sciter-sdk/blob/master/include/sciter-x-types.h#L231
05:50:47FromDiscord<Yardanico> Nimterop makes something like (for the field of the object) SCFN*: proc (a1: SciterClassName)
05:51:33FromDiscord<Yardanico> but it should make SciterClassName: proc() instead (I omitted the pragmas)
05:51:46FromDiscord<Yardanico> Also missed export marker :p
05:53:02*solitudesf joined #nim
05:54:35shashlickLooks like it wasn't preprocessed
05:55:39shashlickAnyway, will check tomorrow, later
05:55:59*vicfred_ quit (Quit: Leaving)
06:08:52*hoijui quit (Ping timeout: 260 seconds)
06:19:32*endragor quit (Remote host closed the connection)
06:20:24*endragor joined #nim
06:25:05*endragor quit (Ping timeout: 256 seconds)
06:44:30*hoijui joined #nim
06:45:54*Cthalupa quit (Ping timeout: 240 seconds)
06:46:25*endragor joined #nim
06:48:56*Cthalupa joined #nim
07:01:35*letto quit (Quit: Konversation terminated!)
07:03:21*letto joined #nim
07:21:33*Tongir quit (Remote host closed the connection)
07:21:57*Tongir joined #nim
07:36:59*debased quit (Quit: WeeChat 2.8)
07:41:44*sagax joined #nim
07:57:13*bung_ joined #nim
08:00:49*bung quit (Ping timeout: 264 seconds)
08:17:44*oddp joined #nim
08:25:46*Shucks joined #nim
08:43:20*nsf joined #nim
08:44:26ForumUpdaterBotNew thread by Hugogranstrom: Question about move semantics for objects and seqs, see https://forum.nim-lang.org/t/6538
08:50:48*Vladar joined #nim
09:04:27*drewr quit (Ping timeout: 260 seconds)
09:06:06*drewr joined #nim
09:07:31*Vladar quit (Quit: Leaving)
09:29:09FromDiscord<Clyybber> planetis[m]: Is your memory leak with your repo also fixed?
09:36:16planetis[m]yes
10:06:17*couven92 joined #nim
10:07:48FromDiscord<Clyybber> oh, nice!
10:41:00*Shucks quit (Ping timeout: 256 seconds)
10:57:46*hoijui quit (Ping timeout: 256 seconds)
11:11:59*couven92 is now known as fredrikhr
11:14:01*Vladar joined #nim
11:14:12*beatmox- quit (Ping timeout: 244 seconds)
11:15:01*qwertfisch quit (Quit: ZNC - http://znc.in)
11:15:05*beatmox joined #nim
11:15:38*qwertfisch joined #nim
11:32:04*waleee-cl quit (Quit: Connection closed for inactivity)
12:06:01*supakeen quit (Quit: WeeChat 2.8)
12:06:26*pbb quit (Read error: Connection reset by peer)
12:06:37*supakeen joined #nim
12:06:55*pbb joined #nim
12:19:42bung_hmm I got `Cannot read property 'id' of null at same_11135072 (app.js:2034)` at two lines
12:20:08bung_while developing karax project, any clue?
12:32:14FromDiscord<Clyybber> Araq: I replied to your review comment
12:33:35Araqwell you removed code and fixed bugs
12:33:43Araqwhat's this magic?
12:33:57Araqhow does it work?
12:34:25FromDiscord<Clyybber> :D
12:36:01FromDiscord<Clyybber> Basically this: When we encounter an expression like stmtListExpr we must insert its destructors and decls into the parent scope, because the result will escape.
12:36:36FromDiscord<Clyybber> (edit) 'stmtListExpr' => 'nkBlockExpr'
12:37:20FromDiscord<Clyybber> and since the result expr may be something like Obj(s: someVarInsideTheBlockExpr) its not correct to destroy s before that
12:43:58Araqdebatable
12:45:14FromDiscord<Clyybber> well, otherwise it will crash :p
12:45:43Araqthere is no reason to delay f()'s destruction in (var tmp = g(f()); tmp)
12:46:06FromDiscord<Clyybber> Yeah, this will be optimized by the eager destructor injection mode I envision
12:46:27Araqwell the code before your PR already does that
12:46:57FromDiscord<Clyybber> Which will inject `=destroy` calls as far "up" as possible, retaining order
12:47:20FromDiscord<Clyybber> Araq: Yeah, but its the wrong aproach IMO
12:47:38FromDiscord<Clyybber> Its easier to just move the destroy calls as far up as possible
12:48:03Araqthe concept of an "escaping expression" is a good one and not the wrong approach
12:48:09*liblq-dev joined #nim
12:48:19*liblq-dev quit (Client Quit)
12:48:21FromDiscord<Clyybber> Yeah, but the escaping expression depends on its scope
12:48:50FromDiscord<lqdev> shashlick: where do I start if I want to generate a standalone wrapper with nimterop?
12:48:52FromDiscord<Clyybber> This is what my PR does, it takes the whole scope with the escaping expression
12:53:44ForumUpdaterBotNew thread by Xflywind: An issue regarding `emit`, see https://forum.nim-lang.org/t/6539
12:55:03FromDiscord<Clyybber> Araq: We could also build a dependency net of expressions that are required for the last expression, but the order in which destructors are added to scope.final is basically that, as in "later vars depend on earlier ones"
12:56:14FromDiscord<Clyybber> And a smarter =destroy injection could simply iterate over the scope.final destroys and insert them as close as possible to their lastRead/Write, retaining the order
13:05:27FromDiscord<Clyybber> Araq: Hmm, actually devel doesn't destroy f() early either
13:05:53FromDiscord<Clyybber> sent a code paste, see https://play.nim-lang.org/#ix=2rrR
13:08:34FromDiscord<Clyybber> Ah, but it does so when a block: is involved
13:56:10*dadada quit (Ping timeout: 246 seconds)
13:58:01*dadada joined #nim
13:58:24*dadada is now known as Guest44090
14:10:11Oddmongerwhat ?! nim> [1,99,2]
14:10:13Oddmonger[1, 99, 2] == type array[0..2, int]
14:10:47FromDiscord<lqdev> ?
14:13:21Oddmongershouldn't it be : type array[1,2,99, int] ?
14:13:42AraqClyybber: I'd appreciate if you fixed the bugs with my code rather than removing it
14:14:13Araqyour version has no explicit 'escapingExpr' concept anymore and that seems harmful.
14:14:34Araqit's too subtle if it just "happens to work because our algorithm is super smart"
14:17:10Oddmongerah i've understood the notation, 0..2 is the number of entries, not the entries themselves
14:19:18*Shucks joined #nim
14:25:47FromDiscord<Yardanico> @Oddmonger if it's easier to you, you can use array[3, int]
14:25:54FromDiscord<Yardanico> which is the same as array[0..2, int]
14:29:07FromDiscord<Clyybber> Araq: But it *has* escapingExpr, its just a boolean now
14:29:12FromDiscord<Clyybber> What is gone is escapingSyms
14:29:28OddmongerYardanico: yes, i was perturbated by the sliced notation, but that's ok
14:29:42FromDiscord<Clyybber> Because my approach pessimistically considers all of them to be potentially escaping since they might be used in the escapingExpr
14:29:44AraqClyybber: hmm
14:29:51Oddmongeri'm still try to understand differences between arrays and seqs (amongts other things)
14:30:03Araqwell maybe it'll grow on me
14:30:24Araqbut I don't like the "pessimistically considers" and then we optimize it away again
14:30:51Araqwriting these optimization passes is not exactly trivial, see my "optimizer.nim" in my branch
14:32:23Araqbtw we should add knowledge about 'ref' to injectdestructors.nim, so that instead of 'wasMoved(tmp); =(tmp, x)' we produce 'if x != nil: incRef(x)' directly
14:33:21Araqwe know how =copy for refs works, we can do it without offering =copy for custom types
14:33:54FromDiscord<Clyybber> hmm, do you want =/=copy to be gone?
14:35:41AraqI'm talking about
14:36:51Araqadding a special case to 'passCopyToSink'
14:37:08FromDiscord<Clyybber> Ah, I see
14:37:20Araqfor n.typ.kind == tyRef
14:37:57FromDiscord<Clyybber> So instead of copying it into a tmp to increase the refcount we would increase it directly and pass it directly instead of the temp?
14:38:28Araqyou can keep the temp but there is no need to 'wasMoved' it
14:38:46FromDiscord<Clyybber> I see. Why would we wasMoved it anyways?
14:38:51FromDiscord<Clyybber> Oh, nevermind
14:38:54Araq:P
14:39:33FromDiscord<Clyybber> Araq: I thought about introducing a `=weak` (or some better name) that would be the `=` hook but without destroying the LHS
14:39:44FromDiscord<Clyybber> Then we could get rid of the wasMoved(tmp)
14:39:55Araqyeah well, I call it =copy
14:39:57FromDiscord<Clyybber> And we could also apply firstWrite optimization to assigns then
14:40:57Araqwe need to be very careful though, already we have '=', '=sink', '=destroy' and undocumented '=dispose' and '=trace'
14:41:54FromDiscord<Clyybber> Yeah
14:42:05*lritter joined #nim
14:42:08Araqwe could remove =sink though and have =copy instead of '='
14:42:38FromDiscord<Clyybber> renamning = to =copy is a good idea IMO
14:42:45Araqit's not a rename!
14:42:58FromDiscord<Clyybber> oh, right, =copy would be = without the LHS destroy?
14:43:03Araqyes
14:43:14Araqjust like a C++ copy constructor
14:43:14FromDiscord<Clyybber> So would we remove `=` then?
14:44:02FromDiscord<Clyybber> I was thinking about it too, wether there is a benefit to have the undestroyed LHS available in `=`
14:44:08Araqyeah but it has downsides
14:44:34Araq1. you cannot do atomic assignments then anymore
14:45:07Araq2. you cannot optimize inside your '=' and keep the allocated buffer around
14:45:26FromDiscord<Clyybber> Hmm, right. Thats a big one
14:46:34*Trustable joined #nim
14:46:36FromDiscord<Clyybber> I guess the best way is to have both the current `=` and `=copy`, If we only have `=copy` we can generate `=` from that. If we only have `=` we simply don't do the firstWrite optimization for assigns
14:46:52Araqand self-assignments become more problematic too
14:47:52Araqbtw even your recent =destroy optimization has downsides
14:48:36*hoijui joined #nim
14:48:40Araqbecause previously we would do 'x.p = nil' but wasMoved(x) might do 'x.len = 0; x.p = nil'
14:49:08FromDiscord<Clyybber> Ideally wasMoved(x) would be overridable
14:49:14FromDiscord<Clyybber> So we could specialize it
14:49:15Araqyeah...
14:50:06Araqspeaking of which, was your =destroy optimization based on real data? looked at some asm code?
14:51:25FromDiscord<Clyybber> The idea no, the idea was yours I think :D But I looked at the asm code afterwards
14:51:29*endragor quit (Remote host closed the connection)
14:51:41FromDiscord<Clyybber> And it got considerably smaller in some of the testcases
14:52:01FromDiscord<Clyybber> Especially after you removed most of the wasMoved calls
14:52:02Araqyou looked at it after optimizations, right?
14:52:09*endragor joined #nim
14:52:10FromDiscord<Clyybber> yeah
14:56:47*endragor quit (Ping timeout: 256 seconds)
14:57:10FromDiscord<Clyybber> seems like C compilers are already relatively eager on inlining `=destroy`
14:59:07FromDiscord<Clyybber> Araq: Regarding the pessimistic approach; do we want to guarantee the order of unrelated destroy calls?
15:00:23Araqnah
15:04:35FromDiscord<Clyybber> hmm, I wonder now when do we actually want to guarantee the order?
15:05:09*endragor joined #nim
15:08:15Araqwell ideally we always want to guarantee the order
15:08:45shashlick@lqdev see how the scintilla wrapper works on feud
15:09:37shashlickBasically you need to set nimFile on cImport
15:09:57FromDiscord<Clyybber> Araq: Yeah, it seems like the most predictable approach. OTOH without aliasing there shouldn't be any "related" destroy calls right?
15:10:31FromDiscord<lqdev> shashlick: and my wrapper will be written to that file?
15:10:39shashlickYes
15:10:43FromDiscord<lqdev> also, are the wrappers 100% independent?
15:10:50FromDiscord<lqdev> apart from the stdlib ofc
15:11:10shashlickOf course cCompile and getHeader don't get forwarded
15:11:17FromDiscord<lqdev> yeah that's fine
15:11:21shashlickYep
15:11:28FromDiscord<lqdev> ok thanks
15:11:35shashlickIf you find bugs, please let me know
15:12:44FromDiscord<lqdev> ok
15:15:16shashlickAnd note that standalone doesn't mean platform independent
15:16:08shashlickYou can write to an os specific file and check into source control if you want assuming you will use the same compiler
15:18:24*waleee-cl joined #nim
15:20:02FromDiscord<Clyybber> shashlick: I was thinking, couldn't you use a sledgehammer approach to making the wrappers platform "independent" by just running them through the C preprocessor with different ifdefs?
15:20:14FromDiscord<Clyybber> (edit) 'ifdefs?' => 'defines?'
15:24:04FromDiscord<Clyybber> and then putting the output in the respective `when blocks`
15:28:49shashlickYes that's possible
15:29:36shashlickBut we need to know both the compiler specific defines as well as the platform specific defines
15:30:25shashlickAnd then I'm not sure if you can tell the preprocessor to ignore its own internal defines and use some other ones
15:31:04shashlickLike `__GNU__` or other weird stuff like that
15:32:08shashlickIt will be easier to do something like binary builder and use cross compilers to generate the wrappers for many targets
15:32:46shashlickBut I'm yet to see nimterop being used to that level to invest that time
15:33:47FromDiscord<lqdev> for some reason I can't call cImport with nimFile
15:34:03FromDiscord<lqdev> I installed latest nimterop
15:34:21FromDiscord<lqdev> oh wait
15:34:23FromDiscord<lqdev> not latest
15:36:47FromDiscord<lqdev> seems like nimterop doesn't like my header
15:37:31FromDiscord<lqdev> shashlick: http://ix.io/2rsn
15:39:25shashlickAdd flags with -d
15:39:32shashlickShould tell you what failed
15:39:38shashlickMight be a bug
15:40:10FromDiscord<lqdev> doesn't change anything
15:40:18shashlickCan then skip or override it while it gets fixed
15:40:34FromDiscord<lqdev> this is my wrapper http://ix.io/2rso/nim
15:40:36shashlickDoesn't it tell you which symbol is failing?
15:40:58FromDiscord<lqdev> nope
15:41:13shashlickIs anything written to the nimFile
15:41:20FromDiscord<lqdev> no
15:41:59shashlickOk remove nimFile and see
15:42:18shashlickI need to debug this - it should write to output or debugging becomes hard
15:42:39FromDiscord<lqdev> got this: # Unsupported node type "call_expression" for node "(FT_UInt32)(0)"
15:43:51*nsf quit (Quit: WeeChat 2.8)
15:46:05*krux02 joined #nim
15:50:12shashlickOk just skip that specific symbol, will have to fix that issue
15:51:43FromDiscord<lqdev> I can't tell what the symbol is
15:52:01shashlickShould tell you in the debug output
15:52:43FromDiscord<lqdev> problem is: it doesn't
15:53:38FromDiscord<lqdev> this is some more output http://ix.io/2rss
15:53:45FromDiscord<lqdev> but above that is some lisp representation
15:53:53FromDiscord<lqdev> which is quite long
15:58:11shashlickYa scroll up, there will be the actual c code printed as well
15:58:27shashlickAlong with the tree sitter ast in lisp style
15:59:05FromDiscord<lqdev> allright
15:59:13FromDiscord<lqdev> seems like it's FT_Encoding
16:03:21FromDiscord<lqdev> yeah I may as well create a small wrapper manually
16:03:30FromDiscord<lqdev> as I only use a few functions
16:03:38FromDiscord<lqdev> pulling everything in is likely gonna slow down compile time
16:04:13*Cthalupa quit (Ping timeout: 256 seconds)
16:05:17shashlickYou only need to do it once but ya it needs to work
16:05:29*Cthalupa joined #nim
16:05:54shashlickDon't import the nimterop wrapper on your main app, import nimFile
16:12:50*bung_ quit (Quit: Lost terminal)
16:19:27FromDiscord<kodkuce> anyone using gitlab i tryed to turn on CI CD but i get this 😦 , ERROR: Job failed: Error response from daemon: pull access denied for nim, repository does not exist or may require 'docker login' (docker.go:119:0s)
16:20:43FromDiscord<kodkuce> .gitlab-ci.yml i put image: "nim:latest"
16:27:35*tane joined #nim
16:39:29FromDiscord<kodkuce> ok got it fix little it was nimlang/nim
16:40:04disruptekneat, bump actually started passing CI in devel.
16:40:09shashlickdisruptek - libgit2 v1.0.1 should be supported now by nimgit2
16:40:20shashlickjust pass -d:git2JBB and -d:git2SetVer=1.0.1
16:40:27shashlickshould work cross OS
16:40:28disruptekwoohoo!
16:40:44disruptekgreat job, dude. so no nimterop dep?
16:41:56shashlickstill need it to pull it
16:42:03disruptekah, okay.
16:42:24disruptekdoes it need toast built?
16:42:48shashlickyep that's what generates the nim wrapper
16:43:01shashlickthis is just the part of pulling precompiled binaries with getHeader
16:43:10shashlickonce that is done, still need to generate the wrapper
16:43:31disruptekokay, so you still need the source, too, then?
16:43:47disruptekor do you use the provided includes, etc. instead of git?
16:44:51shashlickthe package that gets downloaded includes the headers and precompiled libs
16:45:06shashlickso from your perspective, just import nimgit2 and change your flags to -d:git2JBB
16:45:08disrupteknice.
16:54:22FromDiscord<kodkuce> can i cross copile to arm64 ?
16:59:51FromDiscord<lqdev> @kodkuce https://nim-lang.org/docs/nimc.html#cross-compilation
17:02:10FromDiscord<kodkuce> ty, now need to find where arm-linux-gnueabihf-gcc where lives 🙂
17:04:16*endragor quit (Read error: Connection reset by peer)
17:04:54FromDiscord<kodkuce> so raspbery pi 4 uses Cortex-A72 (ARM v8) 64-bit
17:08:28FromDiscord<Clyybber> Araq: WDYT about this simple transformation: `echo (block: var inner = ...; Obj(field: inner))` -> `echo (block: var inner = ...; let tmp = Obj(field: inner); =destroy(inner); tmp)` ?
17:09:24FromDiscord<Clyybber> tmp will then be the only thing getting destroyed in the outer scope
17:09:45Araqdon't we do that? object constructors are sink-polymorphic
17:10:17FromDiscord<Clyybber> We don't do that in my branch anymore. But I think its a better way to solve this then what I do currently
17:10:36Araqwait what?
17:10:49FromDiscord<Clyybber> let me actually check, before I bramble :D
17:10:49Araqin your branch you removed this logic too?
17:11:27FromDiscord<Clyybber> Hmm, no.
17:11:44FromDiscord<Clyybber> But its the logic that will save us from escapingSyms and stuff
17:12:20FromDiscord<kodkuce> kmeee :(↵/usr/lib/gcc/arm-linux-gnueabihf/9.3.0/../../../../arm-linux-gnueabihf/bin/ld: cannot find /lib/libc.so.6 inside /usr/arm-linux-gnueabihf↵/usr/lib/gcc/arm-linux-gnueabihf/9.3.0/../../../../arm-linux-gnueabihf/bin/ld: cannot find /lib/ld-linux-armhf.so.3 inside /usr/arm-linux-gnueabihf↵collect2: error: ld returned 1 exit status
17:14:46*endragor joined #nim
17:19:36*endragor quit (Ping timeout: 256 seconds)
17:20:27FromDiscord<Clyybber> Araq: Well, its not gone as in the Obj won't get destroyed anymore, but its gone as in the =destroy for inner is inserted at the outer scope
17:20:38FromDiscord<Clyybber> But I'll fix that. This seems like the best way to solve all this
17:21:21Araqdon't forget to mention it in your book, "Nim - the C++ish parts"
17:22:23*OMGOMG joined #nim
17:24:06FromDiscord<Clyybber> lol
17:26:03FromDiscord<Clyybber> Araq: Hmm, in a way escapingExpr are similar to sink params as they will be "sinked" to the outer scope
17:26:57disruptekdo they get destroyed only at close of outer scope or at some point before?
17:27:06FromDiscord<Clyybber> At outer scope
17:28:11FromDiscord<Clyybber> But in general we may want an optimization pass that injects/moves the destructors as early as possible
17:38:42FromDiscord<exelotl> "gnueabihf" looks like someone just smooshed their face against the keyboard
17:39:08Araqexelotl: at least it contains vowels so don't complain
17:40:41AraqClyybber: this "optimization pass" is really dangerous and please be aware that to this day C++ cannot model 'tables.getOrDefault' very well because of its overly aggressive destructor injections
17:41:12disruptekbut we might need it for memory consumption reasons.
17:42:55Araqyou can always call 'reset(x)' explicitly to shorten the lifetime further but you cannot easily extend a lifetime
17:43:22AraqIMO scope based destruction is just the right tradeoff
17:44:20disrupteki guess it's always safe to wrap the scope.
17:45:40Araqwell you can use 'block' to get a fresh scope
17:46:01disruptekthat's what i'm saying. it's ugly and heavy-handed, but i guess it's a solution.
17:46:16Araq'reset' is another one
17:46:40disruptekbut you won't have the symbol in scope, right?
17:47:02Araqvar x = f()
17:47:06shashlickAraq: you motivated to debug my arc segfault on the plugins package? it's not quite minimal but less than 800 lines 😄
17:47:13Araquse(x)
17:47:24Araqreset(x) # want to end x's lifetime here
17:47:32AraqmanyMoreLinesOfCode()
17:47:38Araq# block end
17:47:48Araq^ disruptek, is what I mean
17:47:58Araqthough probably you're better off with 'block'
17:48:00disrupteki get that.
17:48:14disrupteki think you don't want people putting their dirty hands on mm thusly.
17:48:27Araqshashlick: sorry, I'm still writing my optimizer. maybe later
17:48:48shashlickokay cool
17:51:57FromDiscord<Clyybber> Araq: WDYM, with respect to getOrDefault?
17:52:49Araqconst T& getOrDefault(Key k, const &T default); // cannot return 'const T&' here if default is returned
17:53:11FromDiscord<Clyybber> Ah
17:53:22FromDiscord<Clyybber> The optimization I'm talking about is not related afaict
17:53:23Araqbecause if the default is a temporary it'll be destroyed too early
17:53:49FromDiscord<Clyybber> Its about putting the =destroy calls for variables as close as possible to their last use
17:54:09Araqno, it is not directly related, but you should have respect
17:54:31Araqwith non-owning views you never really know the "last use"
17:54:57disruptekrespect!
17:55:35FromDiscord<Clyybber> Araq: lets say, last use when we *can* determine it
17:55:46FromDiscord<Clyybber> but I am aware that it could get kinda complex
17:56:27FromDiscord<Clyybber> especially since mapping from the lastUse as found in the DFA to an actual node where we can insert the destructor call in the AST is tricky
17:57:04Araqthat seems a rather simple DFA problem
17:57:06disruptekshashlick: dude, this means we have ssh support on windows, now?
17:57:57Araqclyybber: the DFA can introduce nkLastUse wrapper nodes or a nfLastUse node flag
17:58:21Araqwould make other things simpler too, I think
17:58:40*endragor joined #nim
17:59:17shashlickdisruptek: I believe so
17:59:34shashlickcause it gets downloaded as a dependency
17:59:36FromDiscord<Clyybber> Araq: Ah, I was overthinking it. Its probably not that har
17:59:37disruptekyep.
18:00:47disrupteknimph builds in like ⅓ the time, too.
18:01:22FromDiscord<Clyybber> Araq: Hmm, actually maybe it is a *bit* hard. Since in f(a) where a is the lastUse, we'd want `f(a); =destroy(a)` as the result
18:01:53FromDiscord<Clyybber> So we would have to find the closest parent node in which we can insert our destroy
18:02:26FromDiscord<Clyybber> which is not tricky per se, but searching the AST for each =destroy doesn't sound too efficient
18:03:07disruptekshashlick: you want SetVer:"1.0.1" but gittyup expects "v1.0.1" ... it works, but i'm not sure how.
18:03:33disruptekclyybber: it's more efficient than manual mm.
18:03:49*endragor quit (Ping timeout: 264 seconds)
18:03:51FromDiscord<Clyybber> disruptek: I'm talking efficient as in compile speed
18:03:56disrupteki know.
18:11:04FromDiscord<Clyybber> Araq: Btw, how do {.global.}s work normally? Should we destroy them normally?
18:11:35FromDiscord<Clyybber> Currently theres a weird special case where we check if it has a parent scope, and if not then we add the destructor call to the globalDestructors
18:11:35Araqyeah but .globals are bad, don't use them :P
18:11:41shashlickdisruptek: are you setting `-d:git2JBB`?
18:11:49FromDiscord<Clyybber> Araq: What are they useful for?
18:11:54disruptekshashlick: yeah.
18:12:18Araqsetting up prepared sql statements for example
18:12:27shashlickthen it expects =1.0.1, no v
18:12:38disrupteki know, but take a look at the top of gittyup.nim.
18:12:41Araqevery .global is inited before other non-.global globals
18:12:43shashlickv is only for git2Git
18:13:28shashlickdisruptek: https://github.com/disruptek/gittyup/blob/master/gittyup.nim.cfg#L2
18:13:45shashlickgotta replace that
18:13:59disruptekthat doesn't get read during a nimph compilation.
18:14:23FromDiscord<Clyybber> Araq: Is the RHS in var a {.global.} = ... supposed to be only evaluated once durning the programs lifetime?
18:14:55AraqI think so
18:15:29shashlickdisruptek: this takes precedence - https://github.com/disruptek/nimph/blob/master/src/nimph.nim.cfg#L16
18:15:49disruptekobviously, so again, look at the top of gittyup.nim.
18:16:27FromDiscord<Clyybber> Araq: Heh, arc handle that currently
18:16:46shashlickdisruptek: I don't think nimgit2 sees that const you create
18:16:56shashlickit only sees the value that comes as a -d
18:17:04shashlickor if you use setDefines
18:17:20FromDiscord<Clyybber> *doesn't
18:17:37disruptekit's there so that you can `nim c ...` for testing.
18:17:42FromDiscord<Clyybber> Araq: Should it be deprecated perhaps?
18:17:58disruptekpoint is, i'm looking for v* and otherwise i should issue a warning. but i don't.
18:18:35shashlickyou need v1.0.1 for git cause that's how they create version tags
18:18:39disrupteki don't see the libgit2 version hint, either.
18:18:59shashlickbut for URLs, conan, jbb, etc, it uses the version as is, without a v
18:19:14disrupteki know. that's why i'm asking "why does it work?"
18:20:15shashlickno idea, for whatever reason, nimgit2 uses jbb and version without v cause that's what nimph.cfg has in it
18:20:28shashlickbut in your code, the git2SetVer isn't getting overridden
18:21:10shashlickwhat's the value in gittyup.nim - can you static: echo git2SetVer just for kicks?
18:21:53disruptek1.0.1 of course.
18:22:16disruptekit's curious, right?
18:24:04disrupteki'm really tired of people asking me what my desired salary is.
18:24:13*Cthalupa quit (Ping timeout: 264 seconds)
18:24:32disruptekit's incredibly obnoxious and insulting.
18:24:47disruptekdo you really think i'm going to counter myself before we even talk about the job?
18:25:14disruptekhow about you tell me the most you're willing to pay?
18:25:17disruptekdoes that sound fair?
18:25:30shashlickthey don't want to waste time interviewing someone outside their budget
18:25:39*Cthalupa joined #nim
18:25:55shashlickand you don't want to waste your time interviewing for someone who cannot pay the right salary
18:26:00disruptekgreat, i should value their interview time more than my salary?
18:26:05disrupteki don't think so.
18:26:16disruptekforgive me for prioritizing my well-being over theirs.
18:26:36shashlickyou need to know what your services are worth
18:26:50shashlickif they want to undercut, you don't want to work there
18:26:54disruptekmy services are worth whatever someone else is willing to pay.
18:26:58disruptekthat's how the market works.
18:28:04shashlickyes and employers routinely screw people by asking that question and taking advantage of people who don't know their market worth
18:28:22disruptekof course. i've done it myself.
18:28:32disruptekbut that doesn't mean i'm going to fall into the same trap.
18:28:34shashlickand frankly, no individual really knows their market worth - the power lies with the employers
18:29:35shashlickindeed - i'm not saying it isn't obnoxious but we need to know what we are realistically worth
18:30:20disruptekthe only way to do that is to get offers and share them with others.
18:39:39shashlickdisruptek: so does the new nimgit2 work for you?
18:39:56disruptekseems to; nimph HEAD is using it.
18:40:12*hyiltiz quit (Ping timeout: 260 seconds)
18:40:17*hyiltiz_ joined #nim
18:40:28shashlickcool - should be a bit faster now
18:40:36disruptekwhy is that?
18:40:39shashlickbut it is still shared libs - don't have static libs yet
18:40:44shashlickcause no compiling anymore right
18:40:55disruptekright; it's about 3x faster.
18:51:43*maier joined #nim
18:56:59*Sembei joined #nim
19:01:14*Cthalupa quit (Ping timeout: 240 seconds)
19:02:10*Cthalupa joined #nim
19:02:23*nikita` joined #nim
19:08:40shashlickGood, lots of deps to download
19:09:16shashlickIf we could use msvc .lib files, would be nice
19:09:48shashlickBut Conan also doesn't have new releases
19:15:40*fredrikhr quit (Read error: Connection reset by peer)
19:16:04*fredrikhr joined #nim
19:24:51*hoijui quit (Quit: Leaving)
19:27:18FromDiscord<Clyybber> Araq: The scope of cond in `if cond: ...` is a very curious one :D
19:28:45FromDiscord<Clyybber> I think its best to treat it as if didn't introduce the new scope
19:28:53FromDiscord<Clyybber> but `...` did instead
19:30:04FromDiscord<Clyybber> As we can't transform it intoy `if (var a; destroy(a); cond): ...` as `...` might use `a`
19:30:28FromDiscord<Clyybber> But we can't put the destroy(a) into the `...` either, as it might not get executed
19:30:54FromDiscord<Clyybber> So we have to put it into the parent's scope
19:31:52FromDiscord<impbox> phew, finished my GMTK game jam game ~__~
19:32:02FromDiscord<impbox> 5AM deadline is hard
19:32:56FromDiscord<Elegant Beef> Good job
19:33:00FromDiscord<Elegant Beef> how many levels?
19:33:13FromDiscord<impbox> 15 puzzle levels + one story/tutorial
19:33:24FromDiscord<impbox> the levels needed a lot more work, but ahh well
19:33:30FromDiscord<impbox> can only do so much in 48 hours
19:34:05FromDiscord<impbox> would have liked to add more character/story
19:34:35*vsantana joined #nim
19:34:42FromDiscord<Elegant Beef> No web build?
19:34:50FromDiscord<Elegant Beef> Ah nvm
19:35:01FromDiscord<impbox> https://www.impbox.net/ctrlAltEject/ yep
19:35:15FromDiscord<impbox> only tested in chrome
19:36:48*abm joined #nim
19:38:28*vsantana quit (Client Quit)
19:40:54FromDiscord<Elegant Beef> Just the tutorial was difficult 😄
19:41:04FromDiscord<impbox> yeah... the difficulty is too muich
19:41:06FromDiscord<impbox> (edit) 'muich' => 'much'
19:41:26FromDiscord<impbox> i made the main mechanics all too difficult
19:41:52FromDiscord<Elegant Beef> I think the only reason it's so hard is that you have rotational velocity that needs to be countered
19:42:13FromDiscord<impbox> yep
19:46:45*catcat154 joined #nim
19:47:15catcat154hey, just dropping by to report a few things regarding cross compilation
19:48:05catcat154cross compiling from msys2 latest to linux using the genscript flag produced a shellscript that had gcc.exe at the last line instead of just gcc
19:48:29catcat154also it didnt include nimbase.h (might be intentional)
19:48:49catcat154other than that it worked very well :^)
19:59:56*endragor joined #nim
20:02:31*debased joined #nim
20:03:52*Vladar quit (Quit: Leaving)
20:04:25*endragor quit (Ping timeout: 265 seconds)
20:32:00FromDiscord<Yardanico> @disruptek by the way, after last fixes (probably due to the str v2 mutation optimization) that base64 benchmark is much closer to the default GC with arc
20:32:51disruptekit's twice as fast as it was, and still nearly 3x slower than refc.
20:33:10disruptekas of today's build, anyway.
20:34:20FromDiscord<Yardanico> no
20:34:26FromDiscord<Yardanico> did you try after https://github.com/nim-lang/Nim/commit/6cc0061a72826022991262eb8e31b97f6fdf37e9 ?
20:34:43FromDiscord<Yardanico> I get ~1.5s with refc and ~2.1s with arc
20:34:51disruptekobviously not, since it's not in today's build.
20:37:27*catcat154 quit (Quit: Connection closed)
20:43:05shashlick@Yardanico let me check that sciter wrapper now
20:43:11FromDiscord<Yardanico> oh okay
20:46:00shashlicklet me find your updated wrapper
20:46:14FromDiscord<Yardanico> oh one sec
20:46:37FromDiscord<Yardanico> https://play.nim-lang.org/#ix=2rqX
20:46:45FromDiscord<Yardanico> I also patched that cstring file too
20:46:47FromDiscord<Yardanico> just emptied it
20:46:53FromDiscord<Yardanico> (the file which contained a C++ include)
20:47:58*maier quit (Ping timeout: 256 seconds)
20:48:10FromDiscord<Yardanico> the problem I'm having is that for ISciterAPI for example
20:48:34FromDiscord<Yardanico> "LPCWSTR SCFN( SciterClassName )(void);" with SCFN being a macro results in "SCFN*: proc (a1: SciterClassName): LPCWSTR {.cdecl.}" in Nim
20:49:31Shucksoh gosh
20:49:38shashlicki don't see any such output in my wrapper
20:49:42Shucksthats winapi isnt it ;D
20:49:45FromDiscord<Yardanico> no
20:49:51FromDiscord<Yardanico> it just uses similar type names
20:50:09FromDiscord<Yardanico> @shashlick really? how does ISciterAPI in your generated wrapper look like?
20:51:06shashlickhttps://play.nim-lang.org/#ix=2rtq
20:51:15FromDiscord<Yardanico> oh nice, that looks correct
20:51:20FromDiscord<Yardanico> I wonder why am I getting different results
20:51:25FromDiscord<Yardanico> do I need nimterop head or something?
20:51:31shashlickno this is v0.6.3
20:51:37shashlickwhat version do you have
20:51:46FromDiscord<Yardanico> yeah I have 0.6.3 as well, although I'm on Nim devel if that matters
20:51:59shashlickdo you have some old nimterop@#head sitting around
20:52:13FromDiscord<Yardanico> ah i have 0.6.2 for some reason
20:52:20FromDiscord<Yardanico> removed 0.6.2, still the same
20:52:23shashlickthat shouldn't make a big diffference
20:52:24FromDiscord<Yardanico> (only have 0.6.3 installed)
20:52:45shashlickseems like the preprocessor isn't being run in your case
20:52:58shashlickcan you post your generated wrapper output
20:53:10shashlickwhat OS, gcc version
20:53:37FromDiscord<Yardanico> Artix Linux (Arch fork), GCC 10.1.0
20:53:40FromDiscord<Yardanico> https://gist.github.com/Yardanico/82e03027a386caadaf69f522c6434640
20:55:54shashlickmy wrapper is 3k lines
20:56:05shashlickreally looks like the preprocessor didn't work here
20:56:13FromDiscord<Yardanico> can I debug that somehow?
20:56:47shashlickya the wrapper output you just posted
20:56:58shashlickcan you run the command line on the top directly
20:57:00shashlickbut remove --pnim
20:57:06shashlickthat will print out the preprocessor output
20:57:17FromDiscord<Yardanico> sure
20:57:20shashlickif you can redirect that to a file and see what it looks like
20:58:02FromDiscord<Yardanico> even without --pnim I don't get any output at all
20:58:06FromDiscord<Yardanico> I mean it just writes to a file
20:58:19FromDiscord<Yardanico> or you mean it'll rewrite the file?
20:58:20FromDiscord<Yardanico> with -o
20:58:30shashlickya that's the output
20:58:33shashlickcan you share that output
20:58:51shashlickif it isn't getting preprocessed then we might need to debug https://github.com/nimterop/nimterop/blob/master/nimterop/toastlib/getters.nim#L289
20:58:58FromDiscord<Yardanico> yeah, all macros here are not expanded it seems
20:59:01FromDiscord<Yardanico> https://gist.github.com/Yardanico/8645b403d69d0d1eed970d54743f45ca
20:59:07shashlicktry the command directly with gcc -E
20:59:34FromDiscord<Yardanico> what comamnd?
20:59:38FromDiscord<Yardanico> (edit) 'comamnd?' => 'command?'
20:59:44FromDiscord<Yardanico> ah I see
20:59:44Araqso ... my optimizer works
20:59:46FromDiscord<Yardanico> you mean on that file
20:59:48FromDiscord<Yardanico> yay
20:59:55Araqtime to sleep
21:00:09shashlickya so you can print out the cmd with args sent to startProcess
21:00:19Araqbut seriously guys start to use .raises: []
21:00:19shashlickrun it directly and see why gcc -E isn't giving the right output
21:01:29FromDiscord<Yardanico> hmmm
21:01:37FromDiscord<Yardanico> it doesn't show any errors
21:01:51FromDiscord<Yardanico> but macros aren't expanded, and that SCFN macro isn't in the generated by Nimterop c file at all
21:01:55FromDiscord<Yardanico> I can't find #define SCFN there
21:02:04FromDiscord<Yardanico> in the headers it's in sciter-x-types.h
21:02:07shashlickis getPreprocessor() even getting called?
21:02:33FromDiscord<Yardanico> ?
21:02:45FromDiscord<Yardanico> ah I see what you mean
21:02:51FromDiscord<Yardanico> lemme check, will clone nimterop locally
21:03:32shashlickeither --preprocess is not being recognized by toast which means the file is sent as is instead of preprocessed
21:03:37shashlickor the preprocessor is messing up
21:04:54FromDiscord<Clyybber> Araq: nice!
21:05:26FromDiscord<Yardanico> @shashlick yeah it's processing
21:05:29FromDiscord<Yardanico> the command it's calling is
21:05:37FromDiscord<Yardanico> gcc↵@["-E", "-dD", "-xc", "-w", "-CC", "-I/usr/include/gtk-3.0", "-I/usr/include/glib-2.0", "-I/usr/lib/glib-2.0/include", "-I/usr/include/pango-1.0", "-I/usr/include/cairo", "-I/usr/include/gdk-pixbuf-2.0", "-I/usr/include/atk-1.0", "-I/usr/include/harfbuzz", "-D__attribute__(x)=", "-D__restrict=", "-D__restrict__=", "-D__extension__=", "-D__inline__=inline", "-D__inline=inline", "-D_Noreturn=", "/home/dian/Projects/rimus/src/wrap/sc
21:05:58FromDiscord<Yardanico> and same for other .h files
21:06:13FromDiscord<Yardanico> wait
21:06:15FromDiscord<Yardanico> it's my fault I think
21:06:15FromDiscord<Yardanico> yeah
21:06:17FromDiscord<Yardanico> omh
21:06:37FromDiscord<Yardanico> (edit) 'omh' => 'omg'
21:06:51FromDiscord<Yardanico> it was totally my fault
21:06:59shashlickhow did you pull it off?
21:07:02FromDiscord<Yardanico> I had a modified sciter-x-types.h, sorry for your time 🙂
21:07:07shashlickwill be good to know
21:07:10FromDiscord<Yardanico> and that modified sciter-x-types didn't have SCFN lol
21:07:18shashlickah okay, makes sense
21:07:25FromDiscord<Yardanico> now time to check why "SciterElementCallback" is undeclared
21:07:39shashlickokay, so we still don't have a working wrapper - still some symbols need to be fixed
21:07:55shashlickRECT is from GTK right?
21:08:00shashlickor is your definition good enough
21:08:01AraqClyybber: I have a new idea how to infer .cursor
21:08:27FromDiscord<Yardanico> @shashlick nah, my definition is good enough
21:08:31shashlickthere are also some tree-sitter parse errors so need to figure those out
21:08:33FromDiscord<Yardanico> the other Nim binding was using a similar one
21:08:36FromDiscord<Yardanico> yeah tree-sitter parse error: 'typedef BOOL SC_CALLBACK SciterElementCallback( HELEMENT he, LPVOID param );', skipped
21:08:40FromDiscord<Yardanico> for SciterElementCallback
21:09:05*Trustable quit (Remote host closed the connection)
21:09:37shashlickSC_CALLBACK is not getting preprocessed
21:10:00FromDiscord<Yardanico> for you as well?
21:10:22*audiophile joined #nim
21:10:33shashlickso to avoid parsing all of gtk and everything else, we are turning recurse off
21:10:50shashlickbut in the process, we aren't importing the files as expected by the author
21:10:58FromDiscord<Yardanico> oh
21:11:15shashlickparsing x-dom.h in isolation, we aren't importing SC_CALLBACK which is defined in types
21:11:32*nikita` quit (Quit: leaving)
21:11:42FromDiscord<Yardanico> so how to fix that?
21:11:47FromDiscord<Yardanico> I tried putting types.h before dom.h
21:11:50FromDiscord<Yardanico> in cImport
21:12:06FromDiscord<Yardanico> one way would be to concatenate all .h files in the needed order? 😄
21:12:26shashlickyes correct
21:12:37shashlickthe right way is to recurse but not into all these external packages
21:13:33AraqClyybber: want to hear it?
21:13:53FromDiscord<Yardanico> @Clyybber ^
21:14:17FromDiscord<Clyybber> Araq: Hell yeah
21:15:25Araqwe have 'dest = src'. when do we have to materialize (perform a full copy) 'dest'?
21:16:05Araqonly when either 'src' or 'dest' is mutated
21:16:06shashlickthe other challenge is that they have c++ thrown in in some of the files but we don't want those included either
21:17:08Araqand if 'src' is derived from a non-var parameter we know it doesn't mutate
21:18:11Araq(ofc it helps if func/.noSideEffect becomes stricter)
21:18:11shashlickyardanico: i'm going to add some exclusion capabilities into nimterop so that we can be selective in what gets wrapped
21:18:47FromDiscord<Clyybber> Hmm, interesting
21:18:57Araqthis means every location derived from a parameter is subject to the "No need to materialize" rule
21:19:04FromDiscord<Clyybber> Yeah, and its all just views
21:19:07disrupteki can't remember how to do callsite macros.
21:19:13FromDiscord<Yardanico> @shashlick cool, thanks!
21:20:21Araqpretty much computing all of Rust's borrowed pointers, without the pointers
21:21:41FromDiscord<Clyybber> Yeah, I think its a great idea
21:22:08FromDiscord<Clyybber> Araq: Btw, my handleNested approach was wrong
21:22:27FromDiscord<Clyybber> This `(echo "hey"; a) = (echo "ho"; (a: "b", b: 3))` echoes "hohey" on arc
21:22:32FromDiscord<Clyybber> but it should echo "heyho"
21:23:25FromDiscord<Clyybber> :D
21:23:31Araqyeah well. the spec is something we try to implement but compilers are hard
21:24:18Araqmy outlined optimization amounts to compile-time copy-on-write
21:24:37FromDiscord<Yardanico> lol "Hint: 56367 lines; 0.716s; 77.777MiB peakmem; "
21:25:43FromDiscord<Clyybber> Araq: Yeah, exactly!
21:26:46AraqClyybber: maybe we should give up and do right-to-left evaluation for assignments
21:26:59Araqit's much more natural anyway
21:27:48*tane quit (Quit: Leaving)
21:32:59FromDiscord<Clyybber> Hmm, yeah maybe. What about add then though?
21:33:49*oriba joined #nim
21:34:45Araqadd is left-to-right
21:35:06FromDiscord<Clyybber> But it would also benefit from being right-to-left
21:38:03*NimBot joined #nim
21:38:22Araqwell everything in a single call, ofc
21:38:37FromDiscord<Clyybber> :p
21:41:40Araqhmm cursorfication is essentially the same as our planned stricter .noSideEffect checking
21:41:56Araqso I finally have an excuse to work on that
21:51:00FromDiscord<Clyybber> :D
22:00:44shashlick@Yardanico - got a wrapper done - can you try it?
22:00:48FromDiscord<Yardanico> yes
22:00:52*endragor joined #nim
22:02:58shashlickhttp://ix.io/2rtD
22:03:15shashlickstill need to checkin my changes into nimterop, test, etc
22:03:35shashlickyou need to update the header path, besides that it should work assuming you are on linux x64
22:05:07*endragor quit (Ping timeout: 246 seconds)
22:09:21FromDiscord<Yardanico> how would I pass enums to procs expecting "cuint"?
22:09:26FromDiscord<Yardanico> especially if I need multiple values from that enum
22:09:34FromDiscord<Yardanico> I mean <SCITER_CREATE_WINDOW_FLAGS>
22:09:40*audiophile quit (Ping timeout: 258 seconds)
22:10:26disruptekwrite a converter or cast them.
22:11:05FromDiscord<Yardanico> well I'm asking with regards to nimterop, it does some enum stuff
22:11:10shashlicknimterop includes common conversions to int / cint
22:11:20shashlickbut for other stuff, need to use a converter yes
22:11:24FromDiscord<Yardanico> ah okay
22:11:34FromDiscord<Yardanico> I just cast the set or cast the OR'ing of them?
22:11:35shashlicki don't see why they use cuint
22:11:49disruptekjust pass the set; it'll convert itself.
22:11:51shashlickcast the entire set before passing it down
22:12:01shashlickor converter
22:12:12shashlickconvert SCITER_CREATE_WINDOW_FLAGS to cuint
22:13:08FromDiscord<Yardanico> well I got to the C compiler stage, now it fails because "sciter-x-types.h:220:11: error: unknown type name ‘char16_t’"
22:13:50shashlickamusingly i didn't run into that - i did earlier
22:14:14shashlickjust add a type char16_t = wchar
22:15:11FromDiscord<Yardanico> wait where?
22:15:18FromDiscord<Yardanico> I mean this is a C compiler error in sciter-x-types.h
22:15:34FromDiscord<Yardanico> ah I know what you mean now
22:15:44FromDiscord<Yardanico> or not
22:15:46shashlickoh okay - it's defined in types line 220
22:15:52FromDiscord<Yardanico> yeah
22:16:08shashlickshould be coming from gtk looks like
22:16:16shashlickif !defined(WINDOWLESS)
22:16:30FromDiscord<Yardanico> actually seems like from C++
22:16:31FromDiscord<Yardanico> hrm
22:17:22shashlickactually i am mapping char16_t=cushort,
22:17:39FromDiscord<Yardanico> well but it still errors because it includes the original headers
22:17:53shashlickright - do you need to compile with nim cpp
22:18:16FromDiscord<Yardanico> well I would prefer to use "nim c", but I can try to use nim cpp
22:18:22shashlicka lot of this stuff is c++ headers
22:18:24FromDiscord<Yardanico> the older bindings work with nim c just fine, but they are manually wrapped
22:18:28FromDiscord<Yardanico> well, with c2nim
22:19:28*lritter quit (Ping timeout: 246 seconds)
22:19:47shashlickmaybe you need a wrapper with --noHeader
22:20:43shashlickI can create one but quite a few procs aren't available then
22:20:46shashlickstatic inline ones
22:22:33shashlickif you want that wrapper - http://ix.io/2rtI - you can decide whether those static inline procs aren't important
22:23:00FromDiscord<Yardanico> oh well, these ones are pretty important 😛
22:23:04FromDiscord<Yardanico> they are needed for the DOM manipulation
22:23:19FromDiscord<Yardanico> and passing values between native side and sciter
22:23:20shashlickdo the original wrappers allow for that
22:23:24FromDiscord<Yardanico> yes
22:23:51FromDiscord<Yardanico> e.g. SciterNodeSetText in there is SciterNodeSetText*: proc (hnode: HNODE; text: WideCString; textLength: uint32): SCDOM_RESULT {.stdcall.}
22:23:56FromDiscord<Yardanico> I'm not even sure if that's correct but it works
22:24:25FromDiscord<Yardanico> the author of that fork of original nim bindings only tested it on Windows, and I'm testing on linux 🙂
22:25:02FromDiscord<Yardanico> I will try to fix those C compiler issues
22:26:29shashlicklooks like the proc is available in multiple ways - see the new wrapper, it contains that proc still cause it is declared in 3 places
22:26:46shashlickline 206 and 630 in x-api
22:26:55shashlickso you might still be okay
22:27:00shashlickusing the --noHeader version
22:31:37FromDiscord<Yardanico> yeah I'm trying 😛
22:34:04shashlickokay cool - let me know if any other bugs, will try to fix as soon as possible
22:35:51shashlickcreated a branch called "exclude" which has capability required to generate this wrapper
22:44:12*vicfred joined #nim
22:48:04FromDiscord<Yardanico> so I was getting weird segfaults, but solved it when I put some sciter init logic (for gtk and the dynlib itself) in a separate module
22:52:01shashlickOk so is the wrapper working then? Whatever little you have done so far
22:52:36FromDiscord<Yardanico> well I'm trying with first version you gave me, because it might work too 😛
22:56:17FromDiscord<Yardanico> that's with your noHeader version https://media.discordapp.net/attachments/371759389889003532/732007449833373766/unknown.png
22:56:30FromDiscord<Yardanico> I adapted some code from the old bindings (loading and gtk initialization)
22:57:33FromDiscord<Yardanico> I think your noHeader version should be fine
22:58:32FromDiscord<Yardanico> I'll try porting a more complicated example from old bindings now
22:59:13FromDiscord<Yardanico> this one (it sets a callback to a button in nim, and changes the text on press) https://media.discordapp.net/attachments/371759389889003532/732008190136549526/unknown.png
22:59:35FromDiscord<Yardanico> and yes, I just load Nim's logo from wikipedia (since sciter is html) 😄
23:02:58ShucksGod just wrote some lines in go and realized how much I like nim now.
23:04:19FromDiscord<Yardanico> @shashlick can you share the wrapper code itself?
23:11:50FromDiscord<Varriount> Shucks: Go is ok... although at times it seems to conservative for me.
23:12:09FromDiscord<Varriount> I'd love something like Nim's templates in Go. That would be wonderful.
23:12:50FromDiscord<Varriount> @Yardanico How much memory & CPU does it consume (both idle and when being used)?
23:13:34shashlicklet me post it
23:13:39FromDiscord<Yardanico> Minimal applications (at least for me on Linux, idk about macos/windows) is about 40-55MB I think
23:14:02FromDiscord<Yardanico> library size (on linux) is 8mb (linked dynamically to gtk and stuff)
23:14:10FromDiscord<Yardanico> sciter has it's own html/css/scripting engine
23:14:29FromDiscord<Yardanico> it doesn't use webkit or webviews from other frameworks
23:14:42FromDiscord<Varriount> I'd love to see a comparison on a basic text editor (think notepad) implemented in Nim+Sciter vs Javascript+Electron
23:15:29FromDiscord<Yardanico> well there's already one in sciter + c++
23:15:32FromDiscord<Yardanico> https://github.com/c-smile/sciter-sdk/tree/master/notes
23:15:34FromDiscord<Yardanico> https://html-notepad.com/
23:15:48FromDiscord<Yardanico> and it's not so simple, it's an HTML notepad 😛
23:15:58FromDiscord<Varriount> Although, I do wonder why Sciter isn't more popular. Is it the API?
23:16:03FromDiscord<Yardanico> it's proprietary
23:16:09*fredrikhr quit (Read error: Connection reset by peer)
23:16:23FromDiscord<Yardanico> unless you pay (to compile statically or other stuff)
23:16:24FromDiscord<Varriount> But it's on Github, publically?
23:16:29FromDiscord<Yardanico> well, the binaries - yes
23:16:31FromDiscord<Varriount> Oh, is it like Qt?
23:16:33*fredrikhr joined #nim
23:16:46FromDiscord<Yardanico> you can freely use the binary libraries in any projects, even commercial ones
23:16:56FromDiscord<Yardanico> just need to show that you're using Sciter
23:17:09FromDiscord<Yardanico> @Varriount https://sciter.com/prices/
23:17:22FromDiscord<Yardanico> it's used by a lot of antiviruses apparently
23:17:28FromDiscord<Yardanico> for the UI
23:17:30FromDiscord<Varriount> So, like, in a `Help -> About` menu?
23:17:34FromDiscord<Yardanico> yeah
23:17:41FromDiscord<Varriount> Hm.
23:17:43FromDiscord<Yardanico> https://github.com/c-smile/sciter-sdk/blob/master/license.htm
23:17:56FromDiscord<Varriount> I can see why that would turn a lot of people off.
23:18:16FromDiscord<Yardanico> "Your application shall include link to Terra Informatica site in &quot;About&quot; dialog or similar place in your application. Text of the link: This Application (or Component) uses Sciter Engine (<a href="http://sciter.com/),">http://sciter.com">http://sciter.com/</a>), copyright Terra Informatica Software, Inc.</p>"
23:18:58FromDiscord<Varriount> Wasn't there a similar library/framework that was an open-source alternative to Sciter (not Electron)?
23:19:28FromDiscord<Yardanico> https://ultralig.ht/ maybe?
23:19:47FromDiscord<Yardanico> they use a fork of webkit though
23:20:08FromDiscord<Varriount> Ah, yes, that's what I was thinking
23:20:21FromDiscord<Yardanico> and it's not fully open source either
23:20:26FromDiscord<Varriount> :/
23:20:32FromDiscord<Yardanico> "The UltralightCore and Ultralight modules are proprietary— source code access to these repos can be obtained through a custom license."
23:21:04FromDiscord<Varriount> I can't help but feel that if these libraries went the Qt route, they would pick up more use.
23:21:14FromDiscord<Yardanico> well sciter's author has been considering open sourcing it
23:21:24FromDiscord<Yardanico> He commented about that when replying to questions on HN or similar platforms
23:21:35FromDiscord<Yardanico> the main issue is of course cleaning up the source code and commenting it
23:21:47*abm quit (Quit: Leaving)
23:21:55FromDiscord<Yardanico> I think it's mostly a one-man project, and he's been doing it for over ~14 years
23:22:40FromDiscord<Yardanico> https://sciter.com/sciter-part-i-so-what-is-the-sciter-anyway/
23:22:46FromDiscord<Yardanico> august 2006 😛
23:22:51FromDiscord<Varriount> Hm, if he has various antivirus companies (Norton, Mcafee, etc.) paying yearly licenses, that's quite a big chunk of money.
23:23:08FromDiscord<Yardanico> well I guess they all have the "ENTERPRISE++" license or something 😛
23:23:11FromDiscord<Yardanico> they certainly have the money for it
23:23:17*krux02_ joined #nim
23:23:28FromDiscord<Yardanico> but yeah, seems like you still need to pay each year if you want updated sources
23:24:32FromDiscord<Yardanico> I was really surprised when I found out about it on nim forum
23:24:37FromDiscord<Yardanico> I really didn't hear about it before at all
23:25:07FromDiscord<Varriount> I've heard about Sciter, but discounted it for some reason I can't remember. Probably the license
23:25:11FromDiscord<Yardanico> it also has bindings to d (abandoned), go, python, rust (these ones seem to be updated)
23:25:46*krux02 quit (Ping timeout: 256 seconds)
23:25:48FromDiscord<Yardanico> ah, even .net lol
23:26:03FromDiscord<Yardanico> all hail plain C APIs
23:26:20FromDiscord<Yardanico> (although sciter itself is written C++ as far as I know)
23:26:25FromDiscord<Yardanico> (edit) '(although sciter itself is written ... C++' => '(although sciter itself is writtenin'
23:39:29skrylar[m]apparnetly this has become the sciter channel :ponders:
23:39:58FromDiscord<Yardanico> no no no
23:42:15shashlick@yardanico: https://gist.github.com/genotrance/171c97ab2901f7da9fa0dbfb2999df4a
23:44:36skrylar[m]reminds me. have to redo the bmessage shit
23:44:47skrylar[m]right now it uses this morbidly inefficient message format
23:48:38*oddp quit (Ping timeout: 260 seconds)
23:51:43FromDiscord<Yardanico> redid this example with nimterop's wrapper https://media.discordapp.net/attachments/371759389889003532/732021401694765217/unknown.png
23:51:53FromDiscord<Yardanico> there was difference in how old wrapper and nimterop's define some stuff
23:52:11FromDiscord<Yardanico> @shashlick e.g. SciterWindowAttachEventHandler
23:52:34FromDiscord<Yardanico> the generated wrapper says "hwndLayout: ptr HWINDOW;", but it should be just "hwndLayout: HWINDOW", as in the headers themselves
23:52:56FromDiscord<Yardanico> in the headers it's SCDOM_RESULT SCFN( SciterWindowAttachEventHandler)( HWINDOW hwndLayout, LPELEMENT_EVENT_PROC pep, LPVOID tag, UINT subscription );
23:55:39shashlickHmm, need to see what the preprocessed output is and where that ptr came from
23:55:44shashlickMore work for later
23:55:48shashlickWill check tonight
23:56:07FromDiscord<Yardanico> yeah, thanks again for your work 🙂
23:56:34shashlickIs a good exercise to refine nimterop
23:56:46shashlickAlways some bug or the other
23:57:00shashlickCan you pls open an issue on that
23:57:10FromDiscord<Yardanico> on what exactly? on the ptr thing?