| 00:00:23 | shashlick | nimterop doesn't bail but skips stuff it doesn't recognize, you get a wrapper but it could be missing stuff. Anything referenced that is missing gets caught by compiler though so it's decent |
| 00:01:40 | shashlick | It also defers preprocessing to the preprocessor and allows recursively wrapping |
| 00:01:48 | shashlick | You can |
| 00:02:06 | shashlick | always just check in that generated wrapper and maintain it that way |
| 00:02:26 | shashlick | All said and done, I doubt I have the patience to hand wrap large libs |
| 00:03:25 | * | abm quit (Read error: Connection reset by peer) |
| 00:03:35 | shashlick | It isn't available or maintainable long term |
| 00:26:09 | shashlick | Scalable, but available |
| 00:26:16 | shashlick | Ugh forget it |
| 00:54:34 | * | stefantalpalaru quit (Quit: stefantalpalaru) |
| 01:10:44 | FromGitter | <brentp> with a nim devel, I am getting `../../nim/lib/pure/collections/tables.nim(288, 7) Error: invalid type: 'KeyValuePairSeq[system.string, proc (argv: seq[string]){.locks: <unknown>.}]' for var` on code that used to compile and run. Any ideas? |
| 01:11:25 | FromGitter | <brentp> this code: https://github.com/brentp/genoiser/blob/master/src/genoiser.nim#L653-L669 |
| 01:17:33 | FromGitter | <brentp> work-around: https://github.com/brentp/genoiser/commit/a59d3aeeef282f0f310304f81aa308be47ab47ff |
| 01:19:56 | * | rnrwashere joined #nim |
| 01:22:03 | * | rnrwashere quit (Remote host closed the connection) |
| 01:27:25 | FromGitter | <brentp> also appears that strformat/fmt no longer stringifies bools? |
| 01:30:37 | FromGitter | <brentp> ok: https://github.com/nim-lang/Nim/commit/3a5a0f6d46fa0b43ec223d60b2e0f600305eb5f8 |
| 01:34:42 | * | Cthalupa quit (Ping timeout: 264 seconds) |
| 01:35:56 | * | Cthalupa joined #nim |
| 01:39:34 | * | dddddd quit (Remote host closed the connection) |
| 01:48:00 | FromGitter | <arnetheduck> @shashlick - I'm with @stefantalpalaru on that point - generating a dep on treesitter and all its dependencies just to have wrapping re-run by the whole world on what is a static file is a bit extreme - I think users are better served by a pure .nim file they can just import, as long as that nim file is generated automatically |
| 01:50:04 | FromGitter | <arnetheduck> also, to get to a repro state, you need to lock treesitter itself as well as nimterop, and all treesitter depends on - so many moving parts that each can go wrong - easier to cut off the dependency chain and stay pure nim |
| 02:00:38 | * | theelous3__ joined #nim |
| 02:06:59 | * | banc quit (Quit: Bye) |
| 02:11:00 | shashlick | @arnetheduck - I attempted to explain my rationale in this discussion we had some time ago - https://github.com/nim-lang/Nim/issues/8327#issuecomment-441726793 |
| 02:11:46 | shashlick | nimterop does not force you to depend on it - you can still just generate the wrapper and use it per usual like with c2nim |
| 02:13:48 | FromGitter | <arnetheduck> yeah - we've just been fighting quite a bit with getting repro builds lately and this has surfaced as an issue, as anticipated |
| 02:14:24 | shashlick | with nimgen, I got into the library business, it didn't scale as a one man show so I am putting that knowledge into nimterop and let users use it as they wish |
| 02:14:51 | FromGitter | <arnetheduck> ie at some point you have to draw the line, or you end up with something very impractical.. basically, what I'm saying is that if we were to try to use any libraries that all require pulling in nimterop+deps, it would no longer be feasible - thus any such libraries are likely off limits to us |
| 02:17:24 | shashlick | I understand it gets hard quickly with complex projects, but given how nimterop is today, it doesn't force itself to be a dep, if you have any feedback on that, happy to improve that |
| 02:18:13 | shashlick | here's how I have 3 wrappers being used in the style i'm talking about - https://github.com/genotrance/feud/tree/master/wrappers |
| 02:18:36 | * | c3v0axz quit (Ping timeout: 255 seconds) |
| 02:18:48 | shashlick | but here's a static wrapper of tree-sitter since it is needed to compile nimterop itself - https://github.com/nimterop/nimterop/tree/master/nimterop/treesitter |
| 02:20:17 | FromGitter | <arnetheduck> yeah, I did a first pass on sqlite3 the other day but that failed for whatever reasons - preprocessing helped but led to other problems - have to get back to that at some point |
| 02:21:03 | FromGitter | <arnetheduck> treesitter still looks like it depends on macros & imports |
| 02:24:42 | FromGitter | <arnetheduck> one thing I'm curious about - how do you deal with `#include`? I've been thinking about setting something up for https://github.com/nim-lang/Nim/pull/5698 but it would have rather strict requirements on the wrapper gen, in terms of reusing the right types across includes etc.. `glibc` rivals `system.nim` when it comes to `when`/`#define` jungles.. |
| 02:25:43 | shashlick | that's a good point - nimterop wrappers do depend on https://github.com/nimterop/nimterop/blob/master/nimterop/types.nim |
| 02:25:57 | shashlick | but that's to build a layer of convenience procs that make interop easy |
| 02:26:06 | shashlick | so there's more to nimterop than just the wrapping itself |
| 02:26:35 | shashlick | we could always make it spit out that content as well in the wrapper if required though that's ugly |
| 02:27:44 | * | banc joined #nim |
| 02:30:50 | FromGitter | <arnetheduck> it looks a bit ragtag as well - `time_t`?? the enum stuff could easily just be expanded in the wrapper, |
| 02:31:29 | FromGitter | <arnetheduck> va_list etc - those, in order to get a precise ABI, should probably be parsed as well - else you can't sizeof properly |
| 02:31:58 | FromGitter | <arnetheduck> same with `wchar_t`, whose definition unfortunately depends on compiler flags, often |
| 02:32:42 | shashlick | open to improve all those, basically one place to implement all interop so that every wrapper doesn't need to redo it |
| 02:33:02 | shashlick | i won't claim to be an expert |
| 02:34:14 | FromGitter | <arnetheduck> that's what #5698 is about actually - the std lib has the same problem, it reimports lots of `c` abi stuff in multiple places, sometimes with different definitions in nim |
| 02:40:56 | * | Snircle quit (Quit: Textual IRC Client: www.textualapp.com) |
| 02:40:58 | shashlick | i'd rather offload as much to gcc/clang as it can tell me |
| 02:41:13 | FromGitter | <arnetheduck> I don't want to be an expert, but I unfortunately get to see too much of it :) |
| 02:42:41 | FromGitter | <arnetheduck> that's limited though, because if you can't sizeof/offsetof/alignof, it becomes harder to do many kinds of the slightly non-standard operations that sometimes are necessary at a systems level |
| 02:43:14 | FromGitter | <arnetheduck> non-standard as in, not usually seen in the average script |
| 02:43:49 | shashlick | makes sense |
| 02:43:52 | FromGitter | <arnetheduck> and it affects c wrappers the most - that's actually when you most need it, for example to fill a c union etc |
| 02:44:24 | shashlick | here's a test against mingw's math.h that nimterop runs and generates a functional wrapper - https://ci.appveyor.com/project/genotrance/nimterop-8jcj7/build/job/ajsiygbfs24m5e8j?fullLog=true#L914 |
| 02:44:28 | FromGitter | <arnetheduck> another thing is that it's nice to have these things at compile-time in nim, for example to size an array to a constant that comes from C - not possible otherwise |
| 02:45:28 | shashlick | here's the test wrapper https://github.com/nimterop/nimterop/blob/master/tests/tmath.nim |
| 02:47:16 | shashlick | i only run the preprocessor at this time, can always invoke for other stuff |
| 02:47:37 | FromGitter | <arnetheduck> nice job in general, generated code looks good |
| 02:50:07 | shashlick | thanks 🙂 |
| 02:50:22 | shashlick | let me try sql.h and see how it works |
| 02:51:09 | shashlick | i also need to add {.dynlib.} support, right now it only works with {.header.} |
| 02:52:19 | FromGitter | <arnetheduck> yeah that would be a prime reason to use a generator like this, to be completely independent of the header file - imagine what a boon that would be for windows for example, not to have to download mingw and deal with all that mess |
| 02:57:12 | shashlick | well, you'd still need mingw or similar to compile right? |
| 02:57:31 | shashlick | were you targeting win or lin for sqlite? |
| 02:58:56 | FromGitter | <arnetheduck> both - what I want is an sqlite package that's versioned together with upstream (so I can choose from nim which sqlite version to use), compiles the amalgamation, links statically and offers the raw c api |
| 02:59:58 | FromGitter | <arnetheduck> with nlvm, I won't need mingw, it's stand-alone.. like here: https://twitter.com/jcksie/status/1102589679168376832 |
| 03:02:05 | FromGitter | <arnetheduck> on windows linking is less of a mess there from what little I remember (haven't used windows in a bit, but I'd still like to see support).. though there's no cool appimage format like above, afaik, which makes it harder to distribute a single executable like above |
| 03:03:53 | shashlick | ya i'm on windows most of the time which is why i prefer building source into my packages instead of hunting for dlls |
| 03:04:51 | FromGitter | <arnetheduck> linux is no different - os-supplied packages tend to vary wildly in versions and compile options, so it's hard to rely on them to deliver a working app |
| 03:05:47 | FromGitter | <arnetheduck> except if you deliver it as part of the distro of course - but then it's on the distro to test the app against their cocktail of packages, really |
| 03:07:41 | FromGitter | <arnetheduck> @kaushalmodi was doing some cool stuff with musl as well - that's nice c library that could work well with wrapping, they have very hygienic header files as opposed to glibc |
| 03:09:19 | shashlick | i just used holy build box to make static nim binaries on linux nightlies, seems to be good enough |
| 03:10:20 | shashlick | found dockcross too late |
| 03:35:42 | shashlick | @arnetheduck - here's what I got for sqlite3.h - http://ix.io/1CTQ/nim |
| 03:35:44 | shashlick | compiles too |
| 03:39:23 | FromGitter | <arnetheduck> very nice! what does `codeReordering` do? |
| 03:39:43 | shashlick | order of procs or types doesn't matter |
| 03:39:55 | shashlick | even though nimterop does put all types up top, never know |
| 03:40:29 | shashlick | this is the wrapper file - http://ix.io/1CUl/nim |
| 03:40:31 | FromGitter | <arnetheduck> what about procs that call each other? still need forward decl? |
| 03:41:10 | shashlick | not required, works great |
| 03:41:21 | shashlick | note that this isn't the dynlib version |
| 03:41:30 | shashlick | am looking at whether it is an easy change |
| 03:41:31 | shashlick | should be |
| 03:41:53 | FromGitter | <arnetheduck> oh wow, didn't know that existed even, been bugging me for years.. wonder why it's not default then. |
| 03:42:09 | FromGitter | <arnetheduck> regardless, if the wrapper doesn't need it.. |
| 03:43:01 | leorize | code reordering is experimental and buggy iirc |
| 03:43:02 | FromGitter | <arnetheduck> for header, it looks accurate enough that it shouldn't be needed really - is there an option to not generate header at all? that hard-coded path looks like it might cause trouble if one were to distro that file |
| 03:43:39 | FromGitter | <arnetheduck> forward declarations is what you did in the 1990s |
| 03:44:33 | * | theelous3__ quit (Ping timeout: 255 seconds) |
| 03:45:35 | FromGitter | <arnetheduck> and there's the nimterop import, which in this case looks like it's not even needed - with those two things out of the way, looks like the perfect sqlite wrapper |
| 03:45:45 | shashlick | adding the dynlib option should skip header altogether |
| 03:46:25 | FromGitter | <arnetheduck> oh and one more thing, a `{.compile: "sqlite3.c".}` directive in there as well, can that be generated? |
| 03:46:41 | shashlick | do you mean just have {.importc.} and skip header |
| 03:47:44 | shashlick | just add these two lines and you are done |
| 03:47:52 | shashlick | cCompile("sqlite3.c") |
| 03:47:54 | shashlick | {.passL: "-lpthread".} |
| 03:48:47 | shashlick | http://ix.io/1CUq/nim |
| 03:49:31 | FromGitter | <arnetheduck> yeah, just `{.importc.}` |
| 03:49:44 | shashlick | if you don't like the sqlite3_ prefix, can use cPlugin() to edit the proc symbols |
| 03:50:15 | FromGitter | <arnetheduck> together with ccompile, you *should* end up with a working statically linked sqlite library that way |
| 03:50:34 | FromGitter | <arnetheduck> so what's the command line you used to generate that? |
| 03:51:07 | leorize | shashlick: I think prefix stripping is common enough that you should add a proc or some documentation for it. |
| 03:51:13 | shashlick | just nim c s.nim |
| 03:52:01 | FromGitter | <arnetheduck> I would probably not prefix-strip.. nim's module namespacing is pretty limited, so I'd probably want to reserve the "nice" names for hand-written wrappers on top of that raw c api that would make it nicer to use from nim |
| 03:52:17 | shashlick | on the command line, just toast -pn sqlite3.h but that won't give you the cCompile and passL |
| 03:53:09 | FromGitter | <arnetheduck> so if I want to generate the cCompile as well, into a pre-baked nim file? |
| 03:53:20 | shashlick | cimport adds some conveniences over toast |
| 03:53:50 | shashlick | http://ix.io/1CUq/nim is the wrapper gen file |
| 04:10:20 | FromGitter | <arnetheduck> just for completeness, when compiling with nim, there are some advantages to using `header` still - specially if the header contains compiler-specific instructions that nimterop fails to translate.. this might be hints like `noreturn` etc |
| 04:10:41 | * | nsf joined #nim |
| 04:12:31 | shashlick | so are you saying to leave the header in? |
| 04:13:43 | FromGitter | <arnetheduck> I'm saying the option might be nice, for some situations |
| 04:15:24 | FromGitter | <arnetheduck> option to remove, that is - with how nim is structured today, it's probably better to have it there by default |
| 04:32:39 | FromGitter | <gogolxdong> ../../c/Nim/lib/std/varints.nim(83, 30) Error: cannot copy openArray on latest devel |
| 04:38:43 | * | rnrwashere joined #nim |
| 04:45:51 | * | noeontheend joined #nim |
| 05:17:15 | * | narimiran joined #nim |
| 05:31:28 | * | solitudesf joined #nim |
| 05:52:43 | * | kapil____ joined #nim |
| 05:56:33 | * | rnrwashere quit (Remote host closed the connection) |
| 06:02:48 | * | krux02 joined #nim |
| 06:06:47 | * | noeontheend quit (Ping timeout: 240 seconds) |
| 06:16:28 | * | PMunch joined #nim |
| 06:18:56 | * | cyraxjoe quit (Ping timeout: 268 seconds) |
| 06:20:28 | * | cyraxjoe joined #nim |
| 06:36:20 | * | shomodj quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 06:42:03 | Araq | gogolxdong: we know, fixed. |
| 06:49:44 | * | fanta7531 joined #nim |
| 07:00:00 | * | gmpreussner quit (Quit: kthxbye) |
| 07:01:46 | * | shomodj joined #nim |
| 07:02:15 | FromGitter | <Varriount> Araq: I think you'll like this - https://www.microsoft.com/en-us/research/publication/a-fork-in-the-road/ |
| 07:04:24 | * | gmpreussner joined #nim |
| 07:04:54 | livcd | Is there like a string -like "Foo*" ? |
| 07:15:10 | * | neceve joined #nim |
| 07:24:35 | Araq | Varriount, omg, hell yes |
| 07:32:04 | * | Vladar joined #nim |
| 07:43:59 | * | rockcavera quit (Remote host closed the connection) |
| 07:46:07 | * | Elronnd quit (Remote host closed the connection) |
| 07:48:48 | * | elronnd joined #nim |
| 07:50:26 | * | shomodj quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 07:56:19 | FromGitter | <alehander42> so, is it possible to pass "newline nodes" to renderer.nim |
| 07:56:39 | FromGitter | <alehander42> e.g. a PNode that just signifies i want an additional newline in the rendered output |
| 07:57:00 | Araq | maybe with some hacky nkStmtList |
| 07:57:53 | FromGitter | <alehander42> my problem is |
| 07:57:54 | FromGitter | <alehander42> https://paste.ofcode.org/pFmdKV7R6pSC3Rc5qui7Ga |
| 07:57:57 | FromGitter | <alehander42> here |
| 07:58:15 | FromGitter | <alehander42> all those const/method/call etc nodes are always rendered directly one after another |
| 07:58:35 | FromGitter | <alehander42> instead of e.g. having an addtional empty line |
| 07:59:58 | FromGitter | <alehander42> one thing i thought about is that maybe it makes sense to render nkEmptyNode as a new empty line if its a direct child of nkStmtList |
| 08:00:08 | FromGitter | <alehander42> would this break any assumptions? |
| 08:06:27 | * | floppydh joined #nim |
| 08:08:30 | Araq | no idea, sounds risky |
| 08:09:31 | * | stefanos82 joined #nim |
| 08:10:58 | Araq | instead I would fix the renderer to produce the newlines where you seem fit |
| 08:11:07 | Araq | regardless of empty nodes |
| 08:11:55 | * | ua joined #nim |
| 08:14:05 | FromGitter | <alehander42> yeah it seems if i use it liberally |
| 08:14:08 | FromGitter | <alehander42> i get too many newlines |
| 08:14:18 | * | shomodj joined #nim |
| 08:14:24 | FromGitter | <alehander42> ok, another thing i wondered is if there is a way to just somehow use renderer.nim in "nimpretty" mode |
| 08:14:33 | FromGitter | <alehander42> i thought it would add such things |
| 08:14:41 | FromGitter | <alehander42> otherwise i'add fix the renderer |
| 08:20:47 | FromGitter | <alehander42> ok your idea |
| 08:20:53 | FromGitter | <alehander42> seems to works great for my case |
| 08:20:54 | FromGitter | <alehander42> https://github.com/nim-lang/Nim/pull/10995 |
| 08:21:02 | FromGitter | <alehander42> (are there any renderer tests?) |
| 08:21:35 | Araq | the docgen has tests and so does nimpretty |
| 08:21:45 | Araq | though nimpretty doesn't use the renderer anymore iirc |
| 08:23:18 | FromGitter | <alehander42> hm i guess my change wouldn't really affect docgen but not entirely sure |
| 08:23:39 | FromGitter | <alehander42> should i check for some docgen flag in those cases |
| 08:23:46 | * | elronnd is now known as Elronnd |
| 09:44:13 | * | jjido joined #nim |
| 09:46:38 | * | abm joined #nim |
| 10:04:52 | * | zahary quit (Quit: Connection closed for inactivity) |
| 10:06:08 | * | jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 10:29:12 | * | couven92 joined #nim |
| 10:41:11 | * | neceve quit (Remote host closed the connection) |
| 10:44:59 | * | neceve joined #nim |
| 10:46:23 | * | solitudesf quit (Ping timeout: 246 seconds) |
| 10:56:34 | livcd | can I lookup constants by their value in nim file? |
| 10:56:47 | FromGitter | <mratsim> ctrl+F? |
| 10:58:56 | * | fredrik92 joined #nim |
| 10:59:38 | * | couven92 quit (Disconnected by services) |
| 10:59:56 | * | fredrik92 is now known as couven92 |
| 11:01:35 | narimiran | `gd` if you're using (neo)vim :) |
| 11:09:54 | * | couven92 quit (Read error: Connection reset by peer) |
| 11:11:54 | livcd | i mean programmatically :D |
| 11:12:35 | * | couven92 joined #nim |
| 11:13:09 | Araq | macros.getImpl |
| 11:15:55 | * | fredrik92 joined #nim |
| 11:16:37 | livcd | thx |
| 11:16:48 | * | couven92 quit (Read error: Connection reset by peer) |
| 11:18:51 | * | fredrik92 is now known as couven92 |
| 11:22:13 | Zevv | Varriound: nice find, the fork() paper |
| 11:45:52 | * | rnrwashere joined #nim |
| 11:47:47 | FromGitter | <liquid600pgm> Zevv: thanks for your help with textures :) I wouldn't think that uniforms could be the problem |
| 11:50:07 | * | rnrwashere quit (Ping timeout: 240 seconds) |
| 11:51:24 | PMunch | Hmm, have to do some light web-dev. Karax+Jester is the way to go? |
| 11:53:33 | livcd | I am also going to try karax soon |
| 11:53:44 | PMunch | Hmm, I feel Karax is a bit "too much" for what I need |
| 11:54:36 | Araq | karax is still quite small |
| 11:54:38 | PMunch | I basically just need a page with some text, a couple buttons, and some logic to validate a form. Then the server get's the input, does some work, and responds with a reply |
| 11:54:46 | PMunch | Oh yeah, I wasn't thinking of size |
| 11:55:03 | PMunch | Can I easily use it on just a part of the page? |
| 11:55:34 | PMunch | Basically just a template file with some custom tag that Karax would grab and populate |
| 11:58:10 | * | JustASlacker joined #nim |
| 12:01:15 | * | dddddd joined #nim |
| 12:02:18 | livcd | i just noticed that the example in todoapp references nimcache/todoapp.js but when I do nim js todoapp.nim it creates it in the current directory |
| 12:04:04 | PMunch | That is probably a leftover |
| 12:04:12 | PMunch | nim js used to place the output in nimcache |
| 12:07:48 | livcd | what are you going to create PMunch ? |
| 12:08:29 | PMunch | Small internal tool at work |
| 12:12:48 | * | arecacea1 quit (Remote host closed the connection) |
| 12:13:08 | * | arecacea1 joined #nim |
| 12:24:15 | * | c3v0axz joined #nim |
| 12:29:52 | * | a_b_m joined #nim |
| 12:32:55 | Araq | PMunch, that's easily done with Karax |
| 12:33:10 | * | abm quit (Ping timeout: 250 seconds) |
| 12:33:31 | PMunch | Yeah I just realised that it uses id="ROOT" |
| 12:34:48 | * | rockcavera joined #nim |
| 12:38:46 | * | brakmic joined #nim |
| 12:38:55 | * | brakmic quit (Client Quit) |
| 12:52:35 | PMunch | Hmm, Jester doesn't seem to like files in forms.. |
| 12:55:24 | PMunch | http://ix.io/1FOn/ |
| 12:55:43 | PMunch | Throws an exception when it tries to parse the request |
| 12:56:45 | PMunch | The form looks a little something like this: http://ix.io/1FOo/ |
| 13:03:50 | * | fanta7531 quit (Quit: fanta7531) |
| 13:08:29 | PMunch | Hmm, seems like no forms work. Tried to swap if for a simple text input |
| 13:24:02 | FromGitter | <liquid600pgm> apitrace doesn't want to show filenames in backtraces for some reason, even with `--debugger:native` |
| 13:24:10 | FromGitter | <liquid600pgm> line numbers* |
| 13:25:08 | FromGitter | <mratsim> are you sure it's just not release eating your line numbers? |
| 13:25:19 | FromGitter | <liquid600pgm> yes |
| 13:25:43 | FromGitter | <liquid600pgm> I'm using `nim c --debugger:native -r tests/t_window "windows" "creation"` to compile my program |
| 13:25:59 | FromGitter | <liquid600pgm> (yes I know I'm running it for no reason but that's not the point) |
| 13:26:15 | FromGitter | <liquid600pgm> (https://files.gitter.im/nim-lang/Nim/OqYD/image.png) |
| 13:26:18 | FromGitter | <liquid600pgm> ↑ this is what apitrace shows |
| 13:27:09 | FromGitter | <mratsim> no idea then, usually I either use the raw Nim stacktrace or gdb/lldb backtrace |
| 13:27:34 | FromGitter | <liquid600pgm> I'm trying to debug OpenGL calls so that's not really viable |
| 13:30:33 | * | Snircle joined #nim |
| 13:45:24 | PMunch | Aah, I was missing a response.. |
| 13:45:34 | PMunch | Weird crash though.. Could've been better |
| 13:46:31 | * | chickendan joined #nim |
| 14:02:31 | * | thomasross quit (Ping timeout: 246 seconds) |
| 14:02:58 | * | thomasross joined #nim |
| 14:07:37 | * | PMunch quit (Remote host closed the connection) |
| 14:09:36 | * | vlad1777d quit (Ping timeout: 255 seconds) |
| 14:10:50 | * | vlad1777d joined #nim |
| 14:15:15 | chickendan | Tried sorting a rather large counttable, ran for over ten mins before killing it. Now, is there another fast workaround besides creating a seq and sorting that? https://pastebin.com/x7Vpcvk7 |
| 14:15:53 | * | vlad1777d quit (Ping timeout: 245 seconds) |
| 14:25:22 | FromGitter | <mratsim> SortedTable is missing though maybe strtab can help? |
| 14:26:40 | narimiran | " # we use shellsort here; fast enough and simple" :) |
| 14:27:48 | narimiran | (that's a doc comment for CountTable.sort) |
| 14:30:54 | * | Vladar quit (Remote host closed the connection) |
| 14:52:20 | chickendan | Yeah, narimiran, looking at the github code right now. Shame, because the above would be by far the cleanest solution compared the other languages I've tried. What do you think, would a PR with a faster sorting algorithm be accepted or is this a too obscure of a use case and thus likely a "won't fix"? |
| 14:55:11 | narimiran | chickendan: Araq is the one who can answer that, but my first response would be: "show me the numbers" (i.e. benchmark both your example and some other more common ones (with smaller CountTable)) |
| 15:03:01 | * | akavel joined #nim |
| 15:03:16 | * | akavel quit (Client Quit) |
| 15:05:19 | FromGitter | <akavel> Hi! Do you know if Araq, or anybody from the Nim Core Team, is active now? |
| 15:06:23 | FromGitter | <akavel> I've tried sending a job application letter to [email protected] recently, but then I heard that the hiring is probably already closed now; |
| 15:08:00 | FromGitter | <alehander42> He and narimiran are usually around here most of the time |
| 15:08:01 | FromGitter | <akavel> I'd highly appreciate if I could get a confirmation (I didn't seem to get a response over the week since I sent it). |
| 15:08:14 | FromGitter | <alehander42> So keep an eye here |
| 15:09:45 | FromGitter | <akavel> @alehander42 Ok, cool, thanks! narimiran seems to have been active ~20min ago indeed, so maybe I'll try to ping them... |
| 15:10:14 | narimiran | yes, i'm here, but i'm not the one who you're after |
| 15:11:00 | FromGitter | <akavel> heh, ok :) then do you maybe know who's The One? :D or is it Araq, and Araq only? :D |
| 15:12:14 | FromGitter | <akavel> I tried emailing dom96 already, but he also couldn't confirm with 100% certainty :D |
| 15:14:28 | narimiran | yes, it is him. i guess he's AFK currently, but he's usually here non-stop :) so you'll catch him, don't worry :) |
| 15:16:43 | * | nsf quit (Quit: WeeChat 2.4) |
| 15:17:34 | * | noeontheend joined #nim |
| 15:17:50 | * | JustASlacker quit (Remote host closed the connection) |
| 15:39:45 | disruptek | chickendan: try critbits. |
| 15:40:02 | disruptek | (it will blow your mind) |
| 15:47:14 | disruptek | and please let us know how fast it is. i'm kinda curious after having looked at your paste. |
| 15:49:37 | jken | Is there an environment variable or commandline arg for choosenim that changes where it is installed to? say I want it to live in ~/.env/nimble rather than ~/.nimble |
| 15:50:48 | dom96 | --choosenimDir:<dir> |
| 15:51:08 | dom96 | and --nimbleDir:<dir> |
| 15:51:27 | jken | ah, well look at that. Ill just set those in a choosenim alias |
| 15:51:28 | jken | thanks |
| 15:51:49 | Araq | who summoned me? |
| 15:52:59 | * | floppydh quit (Quit: WeeChat 2.4) |
| 15:53:09 | Araq | better be quick before I watch "Jaedong vs Effort" |
| 15:55:56 | FromGitter | <alehander42> @akavel wanted to know about Nim jobs |
| 15:56:45 | FromGitter | <alehander42> (he sent an email to the Nim lang email but never got an answer: wondered if Nim lang is still hiring) |
| 15:58:12 | Araq | I PM'ed him |
| 15:58:55 | FromGitter | <mratsim> and @chickendan wanted to know if he could implement a faster sort for count table and how likely it is for it to be merged |
| 15:59:23 | FromGitter | <mratsim> though personally maybe we should have a SortedTable and SortedCountTable instead |
| 15:59:40 | Araq | will be merged |
| 15:59:58 | Araq | though it's always sad to replace shellsort :P |
| 16:00:35 | Araq | it means Sedgewick was wrong |
| 16:00:55 | disruptek | Araq: i didn't mean to give you a hard time about `import foo from foo`. ;-) |
| 16:01:14 | disruptek | shellsort is good. critbits is better. |
| 16:02:32 | FromGitter | <mratsim> ah forgot about critbits when I talked about strtabs |
| 16:02:57 | FromGitter | <mratsim> we need a "working with strings in Nim" article |
| 16:03:21 | FromGitter | <mratsim> between the regex/strscans and the tables solutions, it's very easy to forget some modules |
| 16:03:24 | * | solitudesf joined #nim |
| 16:03:52 | FromGitter | <arnetheduck> I can't ever tell how to format string actually.. the two options present are sufficiently similar that there's no compelling reason to use one over the other, and it ends up being pretty random |
| 16:03:53 | * | noeontheend quit (Ping timeout: 250 seconds) |
| 16:04:12 | disruptek | the only compelling reason seems to be avoiding an import. :-D |
| 16:04:25 | Araq | in doubt use &"{x}" |
| 16:04:39 | Araq | but I don't like it ;-) |
| 16:04:49 | FromGitter | <mratsim> I'm happy strformat now works with generics, but AFAIK it's still broken in templates |
| 16:05:12 | FromGitter | <mratsim> Python has 3 ways of formatting strings ;) |
| 16:05:12 | FromGitter | <arnetheduck> well, that's the problem kind of.. there are two bad options essentially |
| 16:05:30 | FromGitter | <alehander42> Well we need to fix strformat |
| 16:05:33 | Araq | no, it's not broken. The rules for template expansions are clear and don't cover "expand within string literals early" |
| 16:06:05 | FromGitter | <alehander42> It's API seems best to me |
| 16:06:59 | FromGitter | <mratsim> BTW https://github.com/nim-lang/Nim/issues/10996 close? |
| 16:07:59 | chickendan | disruptek: critbits is slick indeed, and runs in 33s on my sluggish machine, around as fast as perl and python. Now, but it's only sorting the string mapping, isn't it, or am I missing something? |
| 16:12:21 | Araq | for me all string formats are broken... terrrible single character mini languages that I can never remember |
| 16:15:12 | narimiran | @mratsim isn't now there a documented workaround which makes strformat not-broken in templates? |
| 16:15:52 | * | noeontheend joined #nim |
| 16:16:14 | FromGitter | <mratsim> @Araq & is the same character used for concatenation, much more consistent that Python f-strings and + for concat |
| 16:16:24 | disruptek | chickendan: what is it you are trying to accomplish? can i see your crit code? |
| 16:16:35 | disruptek | should be quite a bit faster than 33s. |
| 16:16:40 | FromGitter | <mratsim> he wants to replace countTable for strings with critbits |
| 16:17:32 | * | c3v0axz quit (Ping timeout: 245 seconds) |
| 16:17:53 | disruptek | right, but without knowing the purpose, it's hard to say if he's using it correctly. ;-) |
| 16:17:58 | chickendan | I want an ascending/descending list of number of occurrences of certain words in a file, think source code dir. |
| 16:18:21 | chickendan | CritBitTree code is virtually the same as before. |
| 16:18:22 | FromGitter | <mratsim> @narimiran you mean this ugly hack? :p https://github.com/nim-lang/Nim/issues/7632#issuecomment-481542932 |
| 16:18:25 | * | avanderneut joined #nim |
| 16:19:12 | disruptek | you want to sort on the number of occurences, right? not the word itself? |
| 16:19:36 | chickendan | Although a tad slower than rust and c++, critbits is on par memory-wise, all are using around 80mb for around 560k of uniq words. Which is fantastic. |
| 16:19:38 | chickendan | Yes. |
| 16:20:11 | chickendan | 50 abc |
| 16:20:13 | chickendan | 30 def |
| 16:20:18 | chickendan | 20 xyz |
| 16:20:20 | chickendan | and so on |
| 16:20:30 | narimiran | @mratsim it is not ugly if it does its job :P |
| 16:20:43 | FromGitter | <mratsim> Brainfuck says hi ;) |
| 16:21:21 | Araq | chickendan, gah slower than C++ and Rust ... we must optimize it further :-) |
| 16:21:44 | chickendan | Nah, that's not what i meant. Runtime before was over 10mins. :) |
| 16:21:53 | Araq | mratsim: try to understand how template expansion really works and the hack disappears |
| 16:22:04 | chickendan | Even interpreted chicken scheme was faster than nim, hehe. |
| 16:22:11 | disruptek | i think i would probably use crit to count the words and then move the data into a structure you can use for your queries. |
| 16:22:13 | Araq | chickendan, how many entries are in the count table? |
| 16:22:26 | chickendan | half a million. |
| 16:22:37 | Araq | and why is shellsort so slow with that... something is wrong |
| 16:22:53 | Araq | half a million is nothing :-/ |
| 16:23:21 | disruptek | crit is great for ooo access, but you cannot quickly query by value. |
| 16:23:55 | FromGitter | <mratsim> @Araq, I already try to understand generics early resolution, if you also throw template late resolution in the mix it gets messy ;) |
| 16:30:03 | * | ua quit (Ping timeout: 268 seconds) |
| 16:30:07 | chickendan | disruptek: crit is indeed a gem, thanks for pointing me in that direction, pretty sure I can utilize that in the future. But for now I'm going with counttable -> seq for sorting, which is fast enough. |
| 16:30:37 | disruptek | is the wordlist public data? i'm kinda curious to play with this problem. |
| 16:34:20 | Araq | fix that bloody counttable.sort already |
| 16:40:25 | shashlick | @arnetheduck, @leorize - from yesterday's conversation, i have the following feedback for nimterop - dynlib support, make header optional, make prefix/suffix easier or better docs, can anything be done for hardcoded header path in generated wrapper, allow standalone wrappers not depending on nimterop/types |
| 16:40:36 | shashlick | any other feedback? let me know - thanks |
| 16:41:59 | disruptek | what's wrong with counttable.sort? |
| 16:42:11 | narimiran | chickendan: in your pastebin you wrote that just populating your CountTable took 20 seconds. can you compare that to other languages, how long does it take them without sorting? |
| 16:42:37 | FromGitter | <arnetheduck> there was one thing I ended up not understanding.. how do I get from http://ix.io/1CUq/nim to a concrete nim file that I can give to someone that doesn't have nimterop installed? you implied the command line tool would not be quite it. |
| 16:42:42 | narimiran | disruptek: didn't we just conclude that it is way too slow? |
| 16:42:55 | disruptek | that's why crit should be used instead. you populate much faster. then you simply move the data into a seq and sort numerically. |
| 16:43:26 | shashlick | @arnetheduck - if you run `nim c wrap.nim`, it will spit out the entire wrapper |
| 16:43:41 | shashlick | can > file.nim and edit it to avoid those issues |
| 16:44:12 | shashlick | that's one of the feedbacks i noted, to make standalone wrappers a bit cleaner |
| 16:47:42 | FromGitter | <arnetheduck> cool - well, there's one final thing I'll be looking into how to do: lock down nimterop version (including all its deps) - nimble is probelmatic in that aspect in that you get a random version every time.. so basically, to create a reproducible wrapper, I also need to make sure I'm using a particular nimterop version |
| 16:48:07 | * | noeontheend quit (Ping timeout: 240 seconds) |
| 16:48:31 | disruptek | if only there were a nim package manager than could yield reproducible builds... |
| 16:49:51 | * | shomodj quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 16:50:18 | shashlick | @arnetheduck - right now, I've not versioned nimterop so that's been a problem - will have to use commits which are ugly |
| 16:50:45 | shashlick | also for wrappers, gitPull() allows to pull specific tag/commit so you can use that to pull upstream and have that committed |
| 16:51:00 | shashlick | that way you can have consistency |
| 16:51:49 | FromGitter | <arnetheduck> well, what I'm likely to do is to lock down to a particular nimterop git hash. the trouble is getting those pesky deps right |
| 16:52:10 | FromGitter | <arnetheduck> regex, cligen, that stuff |
| 16:52:36 | shashlick | okay i see what you are saying, also, nimterop moves as tree-sitter moves |
| 16:52:50 | FromGitter | <arnetheduck> yeah that too |
| 16:52:51 | shashlick | that's easy to lock down since I use gitPull() for upstream |
| 16:53:49 | shashlick | thing though is that while I try to support n, n-1 and n-2 even if possible, sometimes, other lib authors don't quite see the point |
| 16:55:15 | FromGitter | <arnetheduck> my thing is that once I arrive at a working wrapper, I'm unlikely to care about anything you do, until I run into a problem, at which point I'll want to upgrade once, then keep not caring :) |
| 16:55:41 | shashlick | yes and that's totally doable today with some minor fixes which i'm working on |
| 16:58:28 | * | c3v0axz joined #nim |
| 16:58:41 | shashlick | and on my side, I am striving on keeping nimterop running correctly on devel and stable |
| 16:58:49 | shashlick | with all the changes |
| 16:59:28 | shashlick | so hopefully the next time you come to use nimterop, it will work, with more functionality as time permits |
| 16:59:37 | disruptek | i don't see anything wrong with counttable.sort, but i don't understand why we have to scan the entire table to yield largest() or smallest(). can't we keep track of when those values change? |
| 17:00:26 | shashlick | thing is that the CLI is limited when compared to using the cimport API so i will continue to invest in that strategy |
| 17:00:36 | shashlick | there's only so much CLI flags can do |
| 17:01:14 | shashlick | but will continue to support both strategies of using nimterop as a dep or simply checking in the generated wrapper |
| 17:18:09 | * | shomodj joined #nim |
| 17:23:22 | * | rnrwashere joined #nim |
| 17:24:14 | FromGitter | <arnetheduck> shashlick, one more thing - since the codeReordering is not needed and potentially unstable, I'd remove that too, as a feature req |
| 17:27:01 | * | rnrwashere quit (Remote host closed the connection) |
| 17:42:06 | shashlick | Ok i will make it optimal |
| 17:42:19 | disruptek | all i ask is that it's optimal. |
| 17:52:21 | * | luis_ joined #nim |
| 18:01:13 | chickendan | narimiran: sorry for the delay. Sorting is not the issue: c++, rust, python and others execute one or two secs faster when sorting disabled. Furthermore, 20ms is the whole runtime, which includes printing. Piping to /dev/null reduces the nim (sans sort) runtime to around 13s. |
| 18:01:50 | chickendan | disruptek: yes, the data is public since I only stumpled over this problem myself: https://ptrace.fefe.de/wp/timings2019.txt |
| 18:01:55 | chickendan | Check the top lines. |
| 18:02:26 | FromGitter | <arnetheduck> @shashlick https://github.com/arnetheduck/nim-sqlite3-abi - model wrapper library, as I imagine it. someone that depends on `sqlite3_abi` in their nimble file have everything ready, with the same versioning as upstream as well. probably, your `gitPull` is better for most libraries, instead of that `.zip` download, but for sqlite, they have the amalgamation that's really really easy to use |
| 18:02:43 | chickendan | The original plan was to submit a nim multi-threaded version. :) |
| 18:04:08 | narimiran | chickendan: 20ms? you mean 20s, right? if others are 1-2 seconds faster, that's 10% |
| 18:04:22 | chickendan | Oh, yeah, sorry. |
| 18:08:12 | * | shomodj quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 18:10:35 | narimiran | chickendan: and the table with the results you sent is with sorting? i would expect nim to be in that sub-10s crowd |
| 18:12:34 | * | Jesin quit (Quit: Leaving) |
| 18:13:34 | chickendan | The timings are not mine, it's a somewhat public und completely unscientific benchmark initially brought up ten years ago, but was revieved recently. Whole stuff is here, readme contains the whole problem description: https://ptrace.fefe.de/wp/ |
| 18:15:09 | chickendan | The initial goal was to provide idiomatic solutions, but people went the fast route instead. Wanted to see how nice idiomatic nim would hold up and how easy it would be to parallelize the whole damn thing afterwards. |
| 18:24:26 | FromDiscord | <treeform> I heard that we will be getting rid of {.pure.} enums? When? |
| 18:25:43 | * | Jesin joined #nim |
| 18:30:58 | disruptek | chickendan: thanks, i will take a look in a few hrs. :-) |
| 18:32:27 | disruptek | i did make a random word list (random 1-12 char words) >240mb in size, 32MM+ words, and loaded it into crit in <50s single-threaded. |
| 18:32:57 | * | rnrwashere joined #nim |
| 18:33:50 | chickendan | That's because you have a beast of a machine and not a crappy underclocked celeron cpu like I do. :) |
| 18:34:19 | * | rnrwashere quit (Remote host closed the connection) |
| 18:36:03 | disruptek | just a data-point. i'm not even sure my crit accesses are optimal. but at least now we can compare apples to apples. :-) |
| 18:36:50 | * | rnrwashere joined #nim |
| 18:38:02 | * | narimiran quit (Ping timeout: 250 seconds) |
| 18:38:25 | * | narimiran joined #nim |
| 18:39:43 | * | theelous3__ joined #nim |
| 18:46:56 | * | luis_ quit (Quit: luis_) |
| 19:12:33 | dom96 | Seems a 0.19.6 is needed, 0.19.4 has a broken Nimble :( https://github.com/nim-lang/nimble/issues/616 |
| 19:13:05 | shashlick | @arnetheduck - you might want to make those .c and .h paths relative to current path |
| 19:13:08 | shashlick | using currentSourcePath |
| 19:13:17 | shashlick | cause once it is a nimble package, it may or may not work |
| 19:14:34 | FromGitter | <arnetheduck> that's a `devel` feature, right? |
| 19:16:35 | shashlick | no I think currentSourcePath should work even on stable |
| 19:17:26 | shashlick | here's a sample of a nimgen wrapper - http://nimgen.genotrance.com/nimssl/aes.nim.html#L-23 |
| 19:18:31 | * | kapil____ quit (Quit: Connection closed for inactivity) |
| 19:24:49 | ryukoposting | tfw nimcrypto has no releases |
| 19:25:34 | FromGitter | <arnetheduck> @shashlick is there a way to ignore things in the header file / exclude symbols? |
| 19:25:53 | * | nsf joined #nim |
| 19:27:46 | shashlick | yes - you can use cPlugin for fine grained control or cSkipSymbol to just skip them |
| 19:28:01 | shashlick | you can also cOverride to write your own implementation and nimterop will skip them |
| 19:28:16 | shashlick | https://nimterop.github.io/nimterop/cimport.html |
| 19:48:36 | FromGitter | <arnetheduck> nice |
| 19:49:22 | narimiran | dom96: updated nimble is also needed ;) |
| 19:57:25 | * | noeontheend joined #nim |
| 20:01:46 | ryukoposting | Varriount: nimcrypto and httputils don't have any git tags. Until their creators have made official release tags, I can't safely package code that depends on either of them |
| 20:05:32 | ryukoposting | this is absolutely ridiculous, seriously. Who in their right minds would think it makes any sense at all to contribute a package to a public package repository, with the intent that people will download and use it, if they aren't going to version it???? |
| 20:07:06 | rayman22201 | Not defending the lack of tags, but use a git commit hash as a work around? |
| 20:07:18 | ryukoposting | and I don't want to hear any "oh it's still unstable" crap. If it's still too unstable to be used, it doesn't belong in that repository in the first place. If it's still buggy but good enough for people to start trying out, that's what 0.0.x tags are for |
| 20:08:16 | * | shomodj joined #nim |
| 20:08:37 | * | a_b_m quit (Ping timeout: 246 seconds) |
| 20:08:42 | ryukoposting | rayman22201: it works as a kludge, but that's the problem. A git hash gives no indication of the state of the package, its stability, compatibility with other git hashes, etc. |
| 20:09:15 | disruptek | ryukoposting: neither does a version tag. |
| 20:09:34 | FromGitter | <liquid600pgm> are there any good, lightweight sound playback libraries for Nim? |
| 20:09:43 | ryukoposting | they damn well better provide that information disruptek |
| 20:09:46 | krux02 | ryukoposting, versioning is overrated |
| 20:09:49 | disruptek | if your package depends on another, specify which version it depends upon. or, ideally, the git hash. :-) |
| 20:10:14 | krux02 | liquid600pgm: well I use SDL, but I did use sound much yet. |
| 20:10:32 | ryukoposting | krux02 if you honestly think any project that takes itself seriously is going to rely on another package without even being able to specify what version it depends on, then you are out of your damn mind and I might as well kill the AWS project right now |
| 20:10:32 | krux02 | it also really depends on what you want to do. |
| 20:10:49 | * | noeontheend quit (Ping timeout: 250 seconds) |
| 20:10:54 | FromGitter | <liquid600pgm> I just want to play back some small sound effects |
| 20:11:02 | disruptek | hey, don't kill awsome. i like it. i want it. i need it. |
| 20:11:14 | krux02 | ryukoposting, I think you are exaggerating. Quality of software has little to do if it has a version tag or not. |
| 20:11:15 | ryukoposting | you're not the only one disruptek |
| 20:11:53 | ryukoposting | krux02 that's not what I'm saying. What I'm saying is this: If I can't idenfity whether your package is stable, how the hell do I know if it's stable? |
| 20:12:03 | disruptek | by testing it. nawabs ftw! |
| 20:12:05 | krux02 | liquid600pgm: I could succesfully play sound files with SDL |
| 20:12:09 | krux02 | (SDL2) |
| 20:12:29 | FromGitter | <liquid600pgm> yeah, but SDL is pretty heavy and I don't want to pull its entirety into my project |
| 20:12:30 | ryukoposting | If I can't explicitly define a minimum version for a dependency, how the hell am I going to make sure that everyone can use my package without it exploding in their faces? |
| 20:12:44 | FromGitter | <liquid600pgm> I might check out soundio, seems like a fairly lightweight option |
| 20:12:46 | krux02 | it's not that heavy if I know |
| 20:13:02 | krux02 | when you initialize SDL, you can select to only use it's sound component |
| 20:13:23 | FromGitter | <liquid600pgm> yeah, but is it possible to compile *only* the sound component? |
| 20:13:30 | disruptek | again, by testing it and pinning any hash that passes. this is how you, similarly, omit versions of your dependencies that do not work with your software. |
| 20:14:02 | krux02 | well you don't compile SDL anyway. You use a shared library. |
| 20:14:08 | krux02 | all you compile is the SDL2 header. |
| 20:14:25 | krux02 | the nim wrapper uses the full header all the time as far as I know |
| 20:14:31 | krux02 | but it is also not that big. |
| 20:14:50 | FromGitter | <liquid600pgm> I want something I can compile statically, right into my exec, and that wouldn't add too much size |
| 20:15:03 | krux02 | forget about that |
| 20:15:04 | ryukoposting | why is it now my responsibility to filter through every single commit of someone else's package to determine which one is usable? |
| 20:15:17 | krux02 | you need to access the hardware somehow |
| 20:15:26 | FromGitter | <liquid600pgm> I already do that with GLFW, what's the problem? |
| 20:15:27 | krux02 | that only works by interfaces of the operating system |
| 20:15:40 | FromGitter | <liquid600pgm> I just compile it statically |
| 20:15:43 | disruptek | you don't need to track all their changes. you only need to know whether the current hash works. or, bisect until it does. |
| 20:15:53 | krux02 | I think you can compile SDL2 statically as well |
| 20:15:53 | shashlick | @liquid600pgm - there's a bass wrapper - nimbass |
| 20:15:57 | krux02 | but it is not recommended |
| 20:16:03 | ryukoposting | since when did your text editor roll out arbitrary releases online, leaving you responsible for figuring out which one doesn't crash? |
| 20:16:25 | krux02 | SDL2 is designed in a way that it can provide a stable API, even when the operating system under it slightly changes. |
| 20:16:35 | ryukoposting | such a thing would be completely obnoxious, and nobody would use it. I certainly wouldn't, at least. |
| 20:16:35 | disruptek | you don't have to rely upon their code. i'm giving you solutions to your problem. ;-) |
| 20:16:58 | disruptek | what software do you rely upon that you're struggling with? |
| 20:17:02 | shashlick | there's also a soloud wrapper being tested in nimterop |
| 20:17:16 | shashlick | https://github.com/nimterop/nimterop/blob/master/tests/tsoloud.nim |
| 20:18:05 | rayman22201 | https://nimble.directory/search?query=sound |
| 20:18:27 | FromGitter | <liquid600pgm> rayman22201: I'm browsing that rn |
| 20:18:28 | disruptek | also, i DO regularly have to debug other people's code to figure out bugs in my system. i mean, this is the state of the world right now. yes, it's obnoxious. |
| 20:18:42 | shashlick | @liquid600pgm - the soloud wrapper is fully compiled in so might work for you |
| 20:18:44 | * | nsf quit (Quit: WeeChat 2.4) |
| 20:18:49 | shashlick | bass is a separate dll |
| 20:18:57 | FromGitter | <liquid600pgm> nice, I'll try that wrapper out |
| 20:19:14 | krux02 | liquid600pgm: why is it so important to you to have everything statically linked? |
| 20:20:14 | krux02 | hardware interfaces are really better when they are dynamically linked. |
| 20:20:27 | krux02 | best example for this is GPU drivers. |
| 20:20:31 | FromGitter | <liquid600pgm> I just like to have a single, portable executable I can easily share |
| 20:20:40 | shashlick | @ryukoposting - I relate to what you are saying about stability, but how do versions help? if a package does dev in branches and only delivers stable to master, commits should be good too right? |
| 20:21:03 | krux02 | You can write a game in OpenGL and run it on hardware that doesn't even exist yet, because the driven can be injected later |
| 20:21:07 | FromGitter | <arnetheduck> I think what ryokoposting is after a social tool that let's producers of packages give consumers of packages a semi-structured way to discover which versions are expected to mix well, and what their believed state is. this is immensly useful, because you can take that social information, and efficiently pick a set of dependencies to start your testing with - the suggestion to use a git hash doesn't scale well, as |
| 20:21:08 | FromGitter | ... the combinations of versions to try grows quickly. |
| 20:21:41 | shashlick | this is back to the earlier discussion on lock files |
| 20:21:57 | FromGitter | <arnetheduck> once you have that set of packages, you lock it down using git hashes, so it does slip away from under your feet |
| 20:22:04 | disruptek | but you don't need to try all combinations. look at homu/bors. once you have software that works, it should stay working. |
| 20:22:08 | krux02 | so you really should link your SDL2 dynamically and put the dll next to it. |
| 20:22:28 | krux02 | yea it sucks I know |
| 20:22:54 | disruptek | look at lolbench for a demo of git bisecting. it really doesn't have to be as onerous as you suggest. |
| 20:22:56 | krux02 | but that is how it is most likely to run everywhere |
| 20:23:41 | disruptek | that kinda tooling would be a real asset to nim. i wouldn't mind working on it. |
| 20:24:03 | FromGitter | <arnetheduck> disruptek - you assume an automated test suite with full coverage for git bisect to work with. that's optimistic. |
| 20:24:12 | * | narimiran quit (Ping timeout: 250 seconds) |
| 20:24:32 | FromGitter | <arnetheduck> a bit of social lubricant goes a long way, usually. |
| 20:24:38 | disruptek | no, the two are separate. you can bisect locally, or at least in your own branches. |
| 20:25:00 | disruptek | ie. you don't submit a change to upgrade the hashes of your deps until you (at least) have tested them. |
| 20:25:12 | krux02 | arnetheduck: I didn't follow the conversation entirely, what do you want to bisect? |
| 20:25:29 | disruptek | it's the "not rocket science" essay. |
| 20:25:54 | disruptek | i would provide a link, but i'm on a console atm. |
| 20:26:24 | FromGitter | <arnetheduck> disruptek - consider that I use a json library. I want to test that my code works with the new version. what do I use as bisect criteria? |
| 20:26:33 | krux02 | as far as my experiece with ``git bisect`` goes. I thought it would be as frustrating to learn as all the other git workflows. But then when I eventually tried it out, I was surprised how intutive it is. |
| 20:27:12 | disruptek | you run the new version. if it works, great. if not, you bisect between HEAD and the version you depend upon in your master branch. |
| 20:27:41 | FromGitter | <arnetheduck> but I cannot possible run the new version with all the possible json files that exist? |
| 20:27:47 | rayman22201 | The assumption is that you have a reliable and robust way to figure out "it works, great" |
| 20:27:58 | disruptek | if your tests are inconclusive, you have a different problem. |
| 20:28:24 | FromGitter | <arnetheduck> rayman22201, that's the assumption I'm challenging. it doesn't blend well with reality. |
| 20:28:36 | rayman22201 | exactly, I agree with you @arnetheduck |
| 20:28:55 | rayman22201 | I should have elaborated. You can't always have that assumption |
| 20:28:57 | FromGitter | <arnetheduck> indeed - the social glue is there to deal with the inconclusive gray zone |
| 20:29:16 | disruptek | well, frankly, i don't trust the social glue more than my tests. |
| 20:29:41 | disruptek | i mean, you guys seem smart and all, but i'm not going to base the quality of my software on your say-so. :-D |
| 20:30:09 | FromGitter | <arnetheduck> well, you do already, unless you claim that your test suite covers every possible execution of your program |
| 20:30:25 | * | chickendan quit (Quit: Quit) |
| 20:30:53 | disruptek | you say that like it's something infeasible. |
| 20:31:07 | rayman22201 | it is for some cases |
| 20:31:24 | shashlick | the world is a big place |
| 20:31:33 | FromGitter | <arnetheduck> it is, for most cases, specially if you your program is written in a turing complete language :) |
| 20:32:10 | disruptek | symbolic analysis is pretty advanced these days. check out what you can do with KLEE. |
| 20:32:29 | shashlick | if it were so achievable, you'd not see so many software bugs |
| 20:33:11 | disruptek | you're suggesting that the challenge of writing mostly-working software is greater than the challenge of writing provably-correct software. |
| 20:33:22 | disruptek | people are lazy. programmers, especially. |
| 20:34:25 | disruptek | if you can't tell me whether your software works when based upon my software, then how can you criticize me for not having working software? |
| 20:35:04 | FromGitter | <arnetheduck> I'm suggesting that you can't prove correctness, just like you can't prove an argument. you start with a set of axioms from which you build your arguments - same thing with software, you start with a line of trust. that's usually the compiler, and to be efficient, a bunch of libraries as well. you 100% trust your cpu for example, even though history has proven that this is an unsafe assumption. |
| 20:35:59 | FromGitter | <arnetheduck> you can prove correctness according to some criteria in limited, though ever expanding, cases, but that's about it |
| 20:36:06 | shashlick | the fact that there's a human behind anything is a big enough factor |
| 20:36:45 | disruptek | i don't think anyone is arguing that point. the point was, as the publisher of software that depends upon software, you have all the tools you need to ensure stability. |
| 20:36:57 | FromGitter | <arnetheduck> I'm also claiming that it's *efficient* to trust the social glue - you'll produce better outcomes globally if you choose the right trust set. |
| 20:37:10 | FromGitter | <arnetheduck> at least if getting shit done is your objective :) |
| 20:37:12 | disruptek | no one said you had to track changes to underlying dependencies. if it works, use it. you don't have to upgrade. |
| 20:38:03 | disruptek | i guess there are two solutions for ryukoposting, then. :-D |
| 20:38:36 | FromGitter | <arnetheduck> you can't ensure stability - I just gave you an example with the json file. you have to compromise. |
| 20:38:45 | disruptek | ryukoposting: btw, do you have r53 models? |
| 20:39:12 | disruptek | i don't lose sleep over all the json files i won't be able to test. neither should you. ;-) |
| 20:40:12 | shashlick | here's the thing, most production software doesn't change deps unless they have to |
| 20:40:15 | FromGitter | <arnetheduck> I don't. therefore, I also like to rely on a package manager to choose a set of compatible versions for me, based on the social information that developers feed me |
| 20:40:32 | FromGitter | <arnetheduck> then I lock that down and sleep well until I have to change |
| 20:40:33 | disruptek | and, you don't have to change deps. again, just pin the git hash you want. |
| 20:40:39 | FromGitter | <liquid600pgm> shashlick: your soloud wrapper doesn't compile on Nim 0.19.9 |
| 20:40:57 | shashlick | which OS |
| 20:41:01 | FromGitter | <liquid600pgm> Linux |
| 20:41:08 | FromGitter | <liquid600pgm> Fedora 29, to be precise |
| 20:41:21 | FromGitter | <liquid600pgm> there's a ton of linker errors |
| 20:41:23 | FromGitter | <arnetheduck> yes, but that first step of finding a nice set of deps is crucial - it underpins my ability to reuse other people's code, at scale |
| 20:41:56 | disruptek | how you go about that is your business. |
| 20:42:02 | FromGitter | <liquid600pgm> oh wait, I have to compile with nim cpp now |
| 20:42:04 | FromGitter | <liquid600pgm> how annoying |
| 20:42:45 | disruptek | the js ecosystem is a good example of why i don't trust versions AT ALL. |
| 20:42:50 | FromGitter | <arnetheduck> well, yeah. but I think ryukoposting was looking for a method to do that, and it's lacking in several nim libraries |
| 20:42:57 | shashlick | Linux needs the right libs installed, am not testing it on travis |
| 20:43:17 | FromGitter | <liquid600pgm> no, it was just nim cpp |
| 20:43:18 | disruptek | i probably noticed the convo late; what exactly is he looking for? |
| 20:43:40 | shashlick | it should work with nim c too, at least as far as soloud is concerned |
| 20:43:54 | shashlick | soloud is tested on appveyor ubuntu |
| 20:44:01 | shashlick | of course, there's no real sound card |
| 20:44:05 | shashlick | so load fails |
| 20:44:23 | FromGitter | <arnetheduck> the js ecosystem is an amazing feat of human collaboration across the world - with a few bad eggs here and there. easy to poke at those because they're so much more visible. |
| 20:44:34 | disruptek | nim reactor doesn't work with 0.19.9 but it works with 0.19.4. more proof, if you needed it. |
| 20:44:57 | shashlick | https://ci.appveyor.com/project/genotrance/nimterop-8jcj7/build/job/xptwp6wtta04nc5u?fullLog=true#L877 |
| 20:46:10 | disruptek | to me, what's amazing about the js ecosystem is that it works at all. |
| 20:48:05 | FromGitter | <arnetheduck> well, that admission is a strong signal that perhaps they're on to something as well :) not perfect, but perhaps a learning point at least. |
| 20:48:05 | FromGitter | <liquid600pgm> is it possible to disable printing of code generated by nimterop to the console? |
| 20:49:34 | disruptek | i've learned a lot from js. it has changed my code for the better. and part of what i've learned is how much trust i want to put on someone's semver. ;-) |
| 20:50:45 | * | Snircle quit (Quit: Textual IRC Client: www.textualapp.com) |
| 21:03:45 | shashlick | Yes turn debug off |
| 21:04:09 | shashlick | Presuming you are talking about the cimport method and not toast |
| 21:04:27 | shashlick | Remove cDebug() |
| 21:10:39 | * | druonysus joined #nim |
| 21:10:40 | * | druonysus quit (Changing host) |
| 21:10:40 | * | druonysus joined #nim |
| 21:20:58 | FromDiscord | <treeform> @dom96, "Is netpipe a reimplementation of TCP?" - yes and no. TCP is really bad for short latency sensitive messages. TCP was designed for throughput (downloading files) not latency (games). Netpipe will resend stuff faster then TCP, netpipe will not buffer and you also get nat punch-through (which TCP does not have). Netpipe is basically "like TCP but for games". I should write a section about TCP vs netpipe in the readme. |
| 21:21:35 | dom96 | narimiran: I sadly don't have the time to release a new Nimble. |
| 21:21:58 | dom96 | @treeform did I ask that? |
| 21:22:48 | FromDiscord | <treeform> @dom96 not these exact words you said "That's a cool library, but I wonder: isn't this almost a complete reimplementation of TCP? treeform? :)" |
| 21:23:11 | dom96 | ahh right, that was a while ago |
| 21:26:43 | ryukoposting | treeform: sounds an awful lot like UDP to me |
| 21:28:14 | ryukoposting | dom96: hoping to hear your thoughts on this https://github.com/nim-lang/packages/issues/1051 |
| 21:29:36 | dom96 | replied |
| 21:29:38 | FromDiscord | <treeform> ryukoposting, netpipe is built on top of UDP, gives you reliable in order delivery and connection handling just like TCP. |
| 21:29:55 | ryukoposting | ah okay, |
| 21:29:59 | ryukoposting | neat, I like the sound of that |
| 21:33:27 | * | solitudesf quit (Ping timeout: 268 seconds) |
| 21:40:42 | disruptek | wow, i guess counttable.sort IS broken. |
| 21:41:56 | disruptek | takes me only 8s to stuff the words into crit and then 0.7s to pull them out and sort them. all one thread. |
| 21:42:47 | disruptek | 1.8MM words from the llvm sources... |
| 21:43:43 | * | druonysus quit (Quit: druonysus) |
| 21:45:47 | * | druonysus joined #nim |
| 21:45:47 | * | druonysus quit (Changing host) |
| 21:45:47 | * | druonysus joined #nim |
| 21:48:28 | * | vlad1777d joined #nim |
| 22:00:07 | FromDiscord | <treeform> @dom96, @ryukoposting: I have updated the readme https://github.com/treeform/netpipe please let me know if stuff does not make sense. |
| 22:02:26 | ryukoposting | retry for something that's targeted at soft real-time systems seems like a strange choice, but very interesting nonetheless. Sample code looks very good, |
| 22:03:51 | disruptek | counttable can count the words in only 1.5s. something is very broken here. :-( |
| 22:05:23 | FromDiscord | <treeform> ryukoposting, working on RTS games where stuff needs to always sync up. If I was working on an FPS or more action like game, I would implement non-reliable flag, which I think would not be that hard. |
| 22:06:21 | ryukoposting | that's what I was gonna suggest, a one-bit field that says "don't bother retrying this one" |
| 22:07:36 | ryukoposting | (make sure to support async!) |
| 22:14:41 | * | rnrwashere quit (Remote host closed the connection) |
| 22:31:12 | disruptek | 1.5s to count, 0.8s to sort. i'm not happy that crit isn't faster, but at least we fixed counttable and achieved an impressive speed bump. |
| 22:33:03 | * | rnrwashere joined #nim |
| 22:37:07 | * | rnrwashere quit (Ping timeout: 240 seconds) |
| 22:56:06 | * | theelous3__ quit (Ping timeout: 255 seconds) |
| 23:05:12 | * | shomodj quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 23:12:29 | * | rnrwashere joined #nim |
| 23:15:09 | * | rnrwashere quit (Remote host closed the connection) |
| 23:18:37 | * | rnrwashere joined #nim |
| 23:39:22 | * | krux02 quit (Remote host closed the connection) |
| 23:42:57 | * | sz0 quit (Quit: Connection closed for inactivity) |
| 23:45:27 | FromGitter | <deech> Why are `const` objects not allowed? eg. `const O = Object()` is a compiler error |
| 23:54:55 | noonien | hello folks |
| 23:55:06 | noonien | is it possible to cross-compile to armv7 from x86_64? |
| 23:55:37 | ryukoposting | yes, it is |
| 23:55:43 | ryukoposting | deech I'll help you in a sec |
| 23:56:36 | noonien | awesome, thanks! |
| 23:56:41 | noonien | it's a linux target, btw |
| 23:56:49 | ryukoposting | noonien if you set --os:standalone --cpu:arm, that's the first step |
| 23:57:05 | ryukoposting | I'll shoot you an example of the nim.cfg file you'll need |
| 23:57:13 | noonien | that would be awesome! |
| 23:57:21 | noonien | i also need to set the correct CC, right? |
| 23:58:53 | ryukoposting | noonien https://dailyprog.org/f/2g53 |
| 23:59:02 | noonien | ryukoposting: thank you so much! |
| 23:59:23 | ryukoposting | name that bad boy nim.cfg and put it in the same directory as the file you wanna compile, or at the root of the project you wanna compile |
| 23:59:40 | ryukoposting | then change the passC arguments to fit your needs |
| 23:59:42 | noonien | hmm, actually, it should be arm-linux-gnueabh-hf |
| 23:59:53 | noonien | i'm guessin i just change that to --os:linux |
){kind=link}