| 00:14:14 | shashlick | Interesting, I've never seen this - can you please share a snippet the next time you do? |
| 00:14:33 | shashlick | Is it nimble complaining it doesn't know where the stdlib is? |
| 00:14:41 | shashlick | Also which os |
| 00:15:33 | rayman22201 | It's intermittent.... and of course I never stop to record it. It's only really happened to me on Windows. Switching between nim versions will cause the new nim to still reference the previous nim std lib. |
| 00:18:42 | rayman22201 | shashlick, did you see my pm? |
| 00:20:23 | shashlick | Where did you send it? Irc? |
| 00:20:33 | shashlick | I am using matterbridge so won't see that |
| 00:20:51 | shashlick | Alternative is to send genotrance on gitter |
| 00:21:01 | rayman22201 | meh. ok then |
| 00:21:46 | shashlick | I'll setup a pm bridge on irc as well |
| 00:22:01 | * | rnrwashere joined #nim |
| 00:22:38 | FromGitter | <arnetheduck> shashlick, can't, don't have it any more.. :) linux/fedora fwiw. I find the whole nim philosophy of usurping global namespaces and messing with my `$HOME`/`$PATH` by default with stuff like `nimble install` to be quite distasteful, and it inherently doesn't work with choosenim (which nim version compiled what's in `~/.nimble/bin`?) |
| 00:24:18 | rayman22201 | > (which nim version compiled what's in `~/.nimble/bin`?) |
| 00:24:18 | rayman22201 | That is the biggest problem imo |
| 00:25:22 | rayman22201 | shashlick, did you see my gitter pm? |
| 00:27:00 | * | smitop quit (Quit: Connection closed for inactivity) |
| 00:28:20 | * | shashlick_ joined #nim |
| 00:28:31 | * | shashlick quit (Read error: Connection reset by peer) |
| 00:30:07 | * | shashlick_ quit (Remote host closed the connection) |
| 00:30:54 | * | Cthalupa quit (Ping timeout: 246 seconds) |
| 00:33:37 | * | Cthalupa joined #nim |
| 00:37:02 | * | rnrwashere quit (Remote host closed the connection) |
| 00:39:06 | * | rnrwashere joined #nim |
| 00:40:22 | * | Tyresc quit (Quit: WeeChat 2.5-dev) |
| 01:04:59 | rayman22201 | @shashlick I have to take off, but I have the info for you to ssh into my raspberry pi. I just need a private way to give it to you. |
| 01:13:42 | * | Cthalupa quit (Quit: ZNC 1.6.6+deb1ubuntu0.1 - http://znc.in) |
| 01:39:02 | xace | Hahahaha |
| 01:39:19 | xace | oh sorry, i didn't finish scrolling down, my bad |
| 01:50:21 | * | vlad1777d quit (Ping timeout: 246 seconds) |
| 02:03:25 | * | rnrwashere quit (Remote host closed the connection) |
| 02:07:10 | * | banc quit (Quit: Bye) |
| 02:28:29 | * | banc joined #nim |
| 02:43:33 | * | cyraxjoe quit (Ping timeout: 246 seconds) |
| 02:43:49 | * | cyraxjoe joined #nim |
| 02:44:13 | * | kapil____ joined #nim |
| 02:49:17 | * | vlad1777d joined #nim |
| 02:53:56 | * | i7sDream joined #nim |
| 03:02:52 | leorize | Araq: will --newruntime open up for the possibility for interfacing with C using `ref` directly? |
| 03:04:36 | * | rnrwashere joined #nim |
| 03:11:54 | * | vlad1777d quit (Ping timeout: 246 seconds) |
| 03:23:42 | * | [rg] quit (Quit: Leaving.) |
| 03:27:57 | * | Cthalupa joined #nim |
| 03:33:52 | * | [rg] joined #nim |
| 03:53:32 | * | rnrwashere quit (Remote host closed the connection) |
| 04:20:30 | * | Cthalupa quit (Ping timeout: 246 seconds) |
| 04:21:28 | * | Cthalupa joined #nim |
| 04:31:11 | FromGitter | <Varriount> leorize: External C code still won't increment reference counts |
| 04:36:33 | * | nsf joined #nim |
| 04:38:46 | * | shashlick joined #nim |
| 04:42:11 | shashlick | @rayman22201 - sorry got disconnected |
| 04:53:06 | * | kapil____ quit (Quit: Connection closed for inactivity) |
| 04:54:47 | shashlick | @dom96 - here's the choosenim binaries for 0.4.0 |
| 04:54:50 | shashlick | https://www.dropbox.com/sh/u3iyayfzaht9bxr/AADOIJ_eAIy-7f5zEnPVIyvBa?dl=0 |
| 05:49:20 | Araq | https://forum.dlang.org/post/[email protected] as I said, once you stop "thinking about the memory because I have a GC" you get logical leaks |
| 05:53:43 | * | [rg] left #nim (#nim) |
| 05:54:45 | * | solitudesf joined #nim |
| 06:14:16 | FromGitter | <Varriount> Araq: Eh, not as much as you would think. |
| 06:14:38 | Araq | I think they are everywhere and indeed they are. |
| 06:16:58 | FromGitter | <Varriount> I see it more often when someone is trying to (over)optimize memory allocation |
| 06:21:56 | FromGitter | <Varriount> Araq: So I'm taking another independent study course for University, and I'm planning on continuing development of my terminal shell (written in Nim) |
| 06:24:44 | Araq | cool. |
| 06:42:06 | * | Trustable joined #nim |
| 06:50:14 | FromGitter | <gogolxdong> Hi , @Araq, help needed, ⏎ ⏎ ```code paste, see link``` ⏎ ⏎ we need this inline style to be written in the static website string. [https://gitter.im/nim-lang/Nim?at=5cb96fa697dcb371d8d90485] |
| 06:52:41 | * | Trustable quit (Remote host closed the connection) |
| 06:52:59 | FromGitter | <gogolxdong> it not as easy as addEventListener overloading workaround. |
| 06:54:54 | FromGitter | <gogolxdong> to be` style="background-image:url(http://lorempixel.com/600/600/nature/6);" `accordingly. |
| 06:57:25 | FromGitter | <gogolxdong> tried some ideas , haven't worked out. |
| 06:59:57 | * | sz0 joined #nim |
| 07:00:00 | * | gmpreussner quit (Quit: kthxbye) |
| 07:00:10 | Araq | what's the problem? the inline CSS not working? |
| 07:01:55 | FromGitter | <jrfondren> this is karax? did you just not import vstyles? |
| 07:02:07 | * | Minimisthupper joined #nim |
| 07:02:33 | FromGitter | <jrfondren> your exact code works in the todomvc app, when I add vstyles to the list of karax imports |
| 07:03:24 | FromGitter | <gogolxdong> we are talking about static karax website :) |
| 07:04:22 | * | gmpreussner joined #nim |
| 07:04:42 | FromGitter | <jrfondren> yeah. that compiles and it appears in the generated DOM, which you can see with right-click inspect in a browser. with text"" it might now show up, but I saw the background image when I added that style with that code to random existing div with content |
| 07:06:33 | * | Minimisthupper quit (Client Quit) |
| 07:07:31 | FromGitter | <gogolxdong> not virtual DOM , it's an uncommon requirement from the point view of Web APP development, and significant for SEO. |
| 07:07:34 | * | solitudesf quit (Ping timeout: 246 seconds) |
| 07:08:18 | FromGitter | <jrfondren> oh. does karax output HTML? the examples I see all have static .html prepared already. |
| 07:08:43 | * | jjido joined #nim |
| 07:11:27 | FromGitter | <gogolxdong> Dear, it's not static html. |
| 07:11:49 | FromGitter | <Araq> @gogolxdong uses "Native Karax" |
| 07:12:11 | FromGitter | <gogolxdong> What's that |
| 07:12:35 | FromGitter | <Araq> in other words the HTML building DSL for native Nim |
| 07:15:41 | FromGitter | <gogolxdong> I am using nim c for buildHtml, if you mean so. |
| 07:21:22 | FromGitter | <jrfondren> alright, I understand now. so that code works when the output is to virtual dom on the js backend, but's failing to produce the right HTML from the c backend. |
| 07:21:40 | FromGitter | <jrfondren> but I derailed the convo a bit. The important question was Araq asking you what the problem was :) |
| 07:22:45 | FromGitter | <gogolxdong> Don't worry, he knows. |
| 07:24:51 | FromGitter | <jrfondren> ok. then how are you producing HTML? I thought it'd just be `echo $createDom` but the vdom module says it only works on the JS platform |
| 07:25:53 | FromGitter | <jrfondren> oh that's not vdom from karax. that's dom from nim, and I'm only on 0.19.4 |
| 07:28:31 | * | Trustable joined #nim |
| 07:36:24 | * | rockcavera quit (Remote host closed the connection) |
| 07:41:43 | FromGitter | <gogolxdong> you need ⏎ template kxi(): int = 0 ⏎ template addEventHandler(n: VNode; k: EventKind; action: string; kxi: int = 0) = ⏎ ⏎ ```n.setAttr($k, action)``` [https://gitter.im/nim-lang/Nim?at=5cb97bb73b6cb0686a1921bd] |
| 07:43:55 | FromGitter | <gogolxdong> so that karax can generate html tag, attribute , and event. |
| 07:48:47 | FromGitter | <gogolxdong> and use nim c to compile your project.nim file. |
| 07:52:50 | * | Trustable quit (Remote host closed the connection) |
| 07:53:45 | * | rockcavera joined #nim |
| 07:55:19 | FromGitter | <jrfondren> ah ty. looking around for that helped me to find tests/nativehtmlgen.nim |
| 08:01:39 | FromGitter | <mratsim> How did the ACCU talk on Nim hot code reloading went? |
| 08:04:09 | FromGitter | <mratsim> I don't see the talk in ACCU's playlist (it was updated yesterday) |
| 08:07:15 | FromGitter | <jrfondren> (10 minutes of debugging: [] on a non-power-of-2 CountTable results in what looks like an infinite loop. my first step should've been: compile without -d:release) |
| 08:11:45 | FromGitter | <mratsim> 10 minutes is OK :P |
| 08:20:43 | * | kapil____ joined #nim |
| 08:26:36 | * | floppydh joined #nim |
| 08:38:51 | * | chickendan joined #nim |
| 08:46:36 | FromGitter | <jrfondren> using CountTable.sort with 63k keys: 48s. getting a seq of all the pairs and sorting that: 2.5s, with https://gist.github.com/jrfondren/d2a363effffa1e7e1ea3c2eb59f654f3 |
| 08:46:47 | FromGitter | <jrfondren> but with that I've got to go |
| 08:51:45 | * | Vladar joined #nim |
| 08:54:32 | * | neceve joined #nim |
| 09:23:27 | FromDiscord | <SirBroadwell> hi |
| 09:23:34 | FromDiscord | <SirBroadwell> i have found a bug in net package |
| 09:23:51 | FromDiscord | <SirBroadwell> ```nim |
| 09:23:51 | FromDiscord | <SirBroadwell> when isMainModule: |
| 09:23:51 | FromDiscord | <SirBroadwell> import net |
| 09:23:51 | FromDiscord | <SirBroadwell> |
| 09:23:52 | FromDiscord | <SirBroadwell> echo("Hello, World!") |
| 09:23:52 | FromDiscord | <SirBroadwell> let socket = newSocket() |
| 09:23:52 | FromDiscord | <SirBroadwell> socket.bindUnix("/tmp/discord-ipc-0") |
| 09:23:53 | FromDiscord | <SirBroadwell> |
| 09:23:55 | FromDiscord | <SirBroadwell> echo socket.isNil() |
| 09:23:56 | FromDiscord | <SirBroadwell> `` |
| 09:23:58 | FromDiscord | <SirBroadwell> |
| 09:23:59 | FromDiscord | <SirBroadwell> Error : |
| 09:24:00 | FromDiscord | <SirBroadwell> |
| 09:24:01 | FromDiscord | <SirBroadwell> ``` |
| 09:24:03 | FromDiscord | <SirBroadwell> ```nim |
| 09:24:04 | FromDiscord | <SirBroadwell> when isMainModule: |
| 09:24:06 | FromDiscord | <SirBroadwell> import net |
| 09:24:07 | FromDiscord | <SirBroadwell> |
| 09:24:08 | FromDiscord | <SirBroadwell> echo("Hello, World!") |
| 09:24:10 | FromDiscord | <SirBroadwell> let socket = newSocket() |
| 09:24:12 | FromDiscord | <SirBroadwell> socket.bindUnix("/tmp/discord-ipc-0") |
| 09:24:13 | FromDiscord | <SirBroadwell> |
| 09:24:14 | FromDiscord | <SirBroadwell> echo socket.isNil() |
| 09:24:16 | FromDiscord | <SirBroadwell> ``` |
| 09:24:17 | FromDiscord | <SirBroadwell> ``` |
| 09:24:19 | FromDiscord | <SirBroadwell> Error: unhandled exception: Address family not supported by protocol [OSError] |
| 09:24:21 | FromDiscord | <SirBroadwell> ``` |
| 10:03:56 | Zevv | Use let socket = newSocket(AF_UNIX, SOCK_STREAM, IPPROTO_IP) |
| 10:04:13 | FromDiscord | <SirBroadwell> thanks |
| 10:06:27 | Zevv | The higher level socket abstractions default to TCP |
| 10:06:31 | Zevv | makes sense, probably |
| 10:20:40 | * | vlad1777d joined #nim |
| 10:31:37 | * | jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 10:34:13 | * | i7sDream quit (Ping timeout: 245 seconds) |
| 10:36:53 | * | i7sDream joined #nim |
| 10:39:14 | * | lritter joined #nim |
| 10:42:33 | * | i7sDream quit (Ping timeout: 245 seconds) |
| 10:46:59 | FromDiscord | <SirBroadwell> not work 😦 |
| 10:47:08 | FromDiscord | <SirBroadwell> only implentation for <Socket, path> |
| 10:49:55 | * | jjido joined #nim |
| 10:50:15 | Zevv | what's your problem now? I use unix sockets in Nim, works just fine |
| 10:50:28 | Zevv | (btw: please no code dumps on irc, use a paste bin service somewhere) |
| 10:54:01 | FromDiscord | <SirBroadwell> with https://hastebin.com/emuwitovef.bash , i've Error: unhandled exception: No such file or directory [OSError] |
| 10:54:01 | FromDiscord | <SirBroadwell> |
| 10:54:01 | * | jjido quit (Client Quit) |
| 10:54:01 | FromDiscord | <SirBroadwell> But repository exist |
| 10:54:06 | FromDiscord | <SirBroadwell> with https://hastebin.com/emuwitovef.bash , i've Error: unhandled exception: No such file or directory [OSError] |
| 10:54:06 | FromDiscord | <SirBroadwell> |
| 10:54:06 | FromDiscord | <SirBroadwell> But directory exist |
| 10:55:54 | leorize | @SirBroadwell: edits on discord will be seen as multiple messages on IRC, so please avoid doing so |
| 10:56:57 | FromDiscord | <SirBroadwell> ok sorry |
| 10:57:38 | Zevv | @SirBroadwell: who is listening on your unix socket? |
| 10:59:04 | Zevv | You are trying to connect to a unix socket, but if the target socket does not exist on your fs (aka: noone binded that socket), you'll get a "No such file or directory". |
| 10:59:14 | Zevv | Which is the unix equivalent of "connection refused" |
| 11:03:15 | FromDiscord | <SirBroadwell> Oh okay |
| 11:03:20 | FromDiscord | <SirBroadwell> I have success with bindUnix |
| 11:04:06 | FromDiscord | <SirBroadwell> I have little question, with https://hastebin.com/tacifucike.cs how send value in write_byte method ? |
| 11:04:22 | FromDiscord | <SirBroadwell> i'm start nimlang, it's my first exercice |
| 11:07:14 | Zevv | So I guess you want to serialize your OpCode to some kind of binary format? |
| 11:11:05 | * | solitudesf joined #nim |
| 11:16:17 | * | i7sDream joined #nim |
| 11:18:45 | * | i7sDream quit (Client Quit) |
| 11:19:02 | * | i7sDream joined #nim |
| 11:24:26 | FromDiscord | <SirBroadwell> yes |
| 11:26:05 | shashlick | Araq that nimble PR is ready for review. |
| 11:27:00 | Araq | I'm on holidays |
| 11:29:39 | Araq | shashlick: what's working? |
| 11:30:19 | FromDiscord | <SirBroadwell> @Zevv |
| 11:31:06 | Zevv | yes |
| 11:31:34 | Zevv | well, do you need to adhere to some existing protocol, or are you making something here yourself? |
| 11:31:38 | Zevv | what's on the other end? |
| 11:32:58 | * | i7sDream quit (Ping timeout: 245 seconds) |
| 11:34:57 | * | i7sDream joined #nim |
| 11:37:07 | * | stefanos82 joined #nim |
| 11:40:39 | * | matti quit (Ping timeout: 255 seconds) |
| 11:52:58 | * | neceve quit (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
| 11:53:23 | * | neceve joined #nim |
| 12:05:33 | federico3 | a programmatic way to change version in a .nimble file? |
| 12:07:27 | * | kapil____ quit (Quit: Connection closed for inactivity) |
| 12:28:33 | * | solitudesf quit (Ping timeout: 250 seconds) |
| 12:28:53 | Araq | version = "auto" |
| 12:29:16 | Araq | # take it from the git tag |
| 12:29:32 | Araq | we don't have that, but we really need it... |
| 12:30:11 | federico3 | https://github.com/nim-lang/nimble/issues/419 we do not :( |
| 12:32:39 | dom96 | no, what we need is an API that allows the Nim code to retrieve the Nimble version |
| 12:32:45 | dom96 | getPackageVersion() |
| 12:32:52 | dom96 | and get Nimble to pass that via a --define |
| 12:33:26 | dom96 | as far as setting it programmatically goes, we just need a `nimble tag` command |
| 12:33:40 | * | floppydh quit (Quit: WeeChat 2.4) |
| 12:34:19 | * | dddddd joined #nim |
| 12:34:30 | Araq | verions = staticExec("git tag") ? |
| 12:34:36 | Araq | version = staticExec("git tag") ? |
| 12:34:56 | dom96 | no |
| 12:34:59 | * | floppydh joined #nim |
| 12:35:05 | dom96 | stop suggesting these fragile things |
| 12:35:13 | dom96 | the version should be known statically |
| 12:37:38 | * | floppydh quit (Client Quit) |
| 12:37:48 | * | floppydh joined #nim |
| 12:39:32 | federico3 | uhm, nim doc2 --docSeeSrcUrl ... is not putting the URL anywhere |
| 12:39:47 | * | abm joined #nim |
| 12:39:58 | Araq | worked for Nim. |
| 12:45:01 | federico3 | and it's not working here with doc and doc2 |
| 12:45:30 | federico3 | https://github.com/nim-lang/Nim/issues/6071 |
| 12:47:25 | dom96 | sounds like we need to update docs and deprecate --docSeeSrcUrl |
| 12:47:52 | federico3 | "deprecate"? It's broken already |
| 12:48:23 | dom96 | nim doc2 --docSeeSrcUrl -> Deprecated: Please use --git.url and --git.commit instead |
| 12:49:01 | federico3 | https://github.com/nim-lang/Nim/issues/9444 should be reopened to improve the documentation around this |
| 12:49:48 | federico3 | nim --fullhelp does not document those options |
| 12:50:01 | * | kapil____ joined #nim |
| 12:50:23 | Araq | dotted options are not documented |
| 12:50:41 | Araq | and need to die :P |
| 12:52:02 | dom96 | You've merged the PR that introduced them |
| 12:52:34 | federico3 | also the manual has nothing related to documentation generation https://nim-lang.github.io/Nim/manual.html |
| 12:52:49 | dom96 | settle on what we have instead of now changing the format of it yet again |
| 12:53:08 | dom96 | federico3: the manual specifies the language, not the implementation |
| 12:53:50 | federico3 | that does not help the readers |
| 12:54:32 | Araq | dom96: it's worse, I introduced it myself, the idea was that you can set gcc.options.always via the command line |
| 12:56:43 | Araq | probably these config flags should also be checked though. Damn, that will be some work. |
| 12:56:50 | dom96 | what's the problem with it? |
| 12:57:40 | Araq | it's complex, these flags are like $CC.[$OS].[$CPU].(always|debug|release) |
| 12:57:54 | Araq | with optional parts and stuff |
| 12:58:19 | dom96 | so? It works |
| 12:58:52 | Araq | it's not *checked*, make a typo and nobody will notice |
| 12:59:15 | Araq | so that's why foo.bar command line options are not checked either |
| 12:59:36 | Araq | they are passed to the "general purpose" string based subsystem |
| 13:00:03 | FromGitter | <arnetheduck> to replicate python imports, where symbols do not automatically clutter the global symbol table, it's `from xxx import nil`, right? |
| 13:00:06 | dom96 | ok, so give each sub-flag a "used" flag and set it when the flag is retrieved in the compiler |
| 13:00:21 | dom96 | if not, throw an error |
| 13:00:52 | dom96 | this will only give an error at the end |
| 13:00:59 | Araq | arnetheduck: right, but it usually introduces more bugs than it prevents |
| 13:01:05 | dom96 | Certainly there are ways to define these statically ahead of time |
| 13:01:25 | FromGitter | <arnetheduck> @Araq what kind of bugs? |
| 13:01:53 | Araq | you overwrite `==` or `$` for your type 'T' and then you selectively import from the *module* and end up with system.$ and system.== |
| 13:03:24 | FromGitter | <arnetheduck> right, no adl in nim |
| 13:03:46 | Araq | in retrospect C++ got it right with its 'class' keyword :P |
| 13:03:57 | dom96 | adl? |
| 13:04:19 | FromGitter | <arnetheduck> https://en.cppreference.com/w/cpp/language/adl |
| 13:05:01 | dom96 | also, what ever happened to that smart import someone suggested on the Nim forum. The one that would allow you to import types and their corresponding procs? |
| 13:05:20 | dom96 | That sounds like it would make people happy |
| 13:05:53 | Araq | I annoyed the contributor who worked on it. |
| 13:10:44 | Araq | also it would be yet another feature to learn, I prefer to fix real language deficiencies |
| 13:11:20 | Araq | if your module has so many unrelated crappy procs that you don't want to import, maybe make the mmodules smaller |
| 13:12:46 | Araq | plus `import x except a, b, c` works well IME |
| 13:13:46 | FromDiscord | <SirBroadwell> I want to make a rich presence for discord @Zehh |
| 13:14:05 | FromDiscord | <SirBroadwell> I have to send my opcode in the write_byte but I can't |
| 13:15:26 | FromGitter | <arnetheduck> we're a bit stuck on that front - making smaller modules means it's hard to name them and the module-unique-name-thing bites us.. we also can't make smaller packages because the tooling is not up for it (hard to have multiple packages in single git repo and hard to manage multiple git repos) |
| 13:15:43 | FromGitter | <arnetheduck> on smaller projects, I guess it's not that much of an issue but.. |
| 13:15:52 | dom96 | @SirBroadwell I guess you're reimplementing Discord's Rich Presence lib? Why not just use it? |
| 13:16:33 | dom96 | > hard to have multiple packages in single git repo |
| 13:16:34 | dom96 | Why? |
| 13:17:10 | federico3 | don't the nimble files conflict? |
| 13:17:31 | dom96 | no, as long as they're in separate dirs |
| 13:18:12 | federico3 | nimble does not break with not having a .nimble file at the root? |
| 13:18:15 | FromGitter | <arnetheduck> something with nimble afair. though I guess we can stop worrying about that now that we've moved on.. |
| 13:18:58 | * | a_b_m joined #nim |
| 13:19:43 | Araq | arnetheduck: I don't know if it helps your use cases but `import x except ...` works much better than `from x import nil` |
| 13:19:49 | FromGitter | <arnetheduck> basically, we want a monorepo with lots of packages in it, and we want to cross-ref those "internally" |
| 13:22:13 | dom96 | Any reason why you cannot just use Nim's --path for this? |
| 13:22:18 | * | abm quit (Ping timeout: 246 seconds) |
| 13:22:26 | dom96 | You shouldn't even need Nimble |
| 13:22:55 | Araq | please don't use --path, use relative addressing :-) |
| 13:23:17 | Araq | --path predates import ".." / [foo, bar, baz] |
| 13:23:42 | FromGitter | <arnetheduck> we can and we are. Stefan came up with some hack where we create a bunch of fake nimble files that only set the paths correctly - they don't work with nimble, but they satisfy the nim compiler which reads the same file. a thing of beauty :) |
| 13:23:44 | dom96 | really? You want to manually fix all those import paths whenever a module is moved around? |
| 13:24:16 | dom96 | The Nim compiler only needs an empty file called `pkg.nimble` |
| 13:24:29 | dom96 | Remember: `pkg.nimble` is the same as __init__.py in Python |
| 13:24:31 | Araq | dom96: yes. I can understand that others don't like that, but I prefer it this way. |
| 13:25:20 | Araq | but I'm probably super biased since I don't really use sub directories |
| 13:25:28 | FromGitter | <arnetheduck> relative addressing, unless it somehow magically avoids the unique-module-name thing, breaks for `a/util` and `b/util` |
| 13:26:03 | dom96 | inb4nameyourmodulesomethingelse :P |
| 13:28:42 | FromGitter | <arnetheduck> well, the english language is such that many words are overloaded depending on the domain.. `util` is a silly example mostly because every project ends up with that kind of dumping ground.. |
| 13:28:43 | Araq | I have 3 different tester.nim files and always pick the wrong one, I'll rename them soon. unique names ftw. |
| 13:30:04 | Araq | in theory I could always write testament/tester.nim but I don't and so it shall be testament.nim |
| 13:31:46 | dom96 | testament/tester.nim implies that it's a tester for testament |
| 13:31:55 | dom96 | so yes, testament.nim is much better |
| 13:32:11 | Araq | nimpretty/tester.nim really tests nimpretty though :P |
| 13:33:21 | FromGitter | <arnetheduck> all the solutions along the line of "just name your stuff better" presume you're in a position to affect the naming, but often you're not - 3rd party libs, domain-specific structures etc.. |
| 13:34:08 | FromGitter | <arnetheduck> ie the perspective that the world should adapt to you doesn't quite scale |
| 13:34:49 | FromGitter | <yglukhov> imo it's a scalability issue. imagine a project with hundreds of files in complex hierarchies and programmers who don't even know each other working on it. The first programmer who "reserves" a file name is lucky :). But it can get worse than that actually. The collision might be commited and exist unnoticed for a while if it's imported under `when defined`. And then some "irrelevant" change reveals the collision, and |
| 13:34:49 | FromGitter | ... all of the project members are like wtf. This story is taken from the real life :) |
| 13:34:50 | Araq | yeah but 3rd party libs have the .nimble file and then Nim shuts up about it |
| 13:34:52 | dom96 | indeed |
| 13:35:27 | dom96 | and then you'll get two nimble packages with the same name and you're fucked :P |
| 13:36:08 | FromGitter | <yglukhov> btw, 2 nimble packages with the same name can and should also be allowed and handled. |
| 13:36:21 | FromGitter | <yglukhov> but that's a different story |
| 13:44:01 | Araq | my /usr/bin has 1054 files. I don't like it but I don't see articles how "UNix doesn't scale" either |
| 13:49:50 | FromGitter | <yglukhov> i didn't say "it doesn't scale". i said it's an issue. yeah, i don't encounter it every day, but still this limitation seems just too unnatural. i.e. I don't see a reason for the semantics to disallow duplicates. |
| 13:57:27 | Araq | there are 2 reasons for it: |
| 13:57:50 | Araq | 1. I thought it nudges you into good development practices. (I still think it so.) |
| 13:58:37 | Araq | 2. pkg_module needs to be unique for (easier/deterministic) C code generation. |
| 14:02:15 | FromGitter | <yglukhov> 1) You can't really use that as an argument. You gan't measure goodness and rightness of development practices. Judging from how often this topic is touched by the community, I would conclude that sometimes this practice might be "good". |
| 14:02:28 | FromGitter | <yglukhov> 1) That's an implementation detail, not design. |
| 14:02:55 | Araq | it doesn't matter, it's a real problem with no obvious solution |
| 14:03:57 | FromGitter | <yglukhov> really? why? |
| 14:04:47 | FromGitter | <yglukhov> here's one immediately obvious solution. reflect dir structure in nimcache like java does. |
| 14:05:03 | Araq | it's not about the directory structure |
| 14:05:31 | Araq | I need to generate nimble_module_init procs, for example |
| 14:06:06 | Araq | and I don't want to have home_araq_projects_nim_compiler_ast_init() names |
| 14:06:32 | Araq | that's not only too long, it's also machine specific code which would be harder to test |
| 14:07:27 | FromGitter | <yglukhov> it doesn't have to be absolute. you always have project root, no? :) |
| 14:08:10 | FromGitter | <yglukhov> but you're right. it's *slightly* more complex than I envisioned. still pretty obvious ;) |
| 14:08:59 | Araq | what's the project root? if I compile with 'nim c src/main' I get totally different C code than if I do 'cd src && nim c main' ? |
| 14:09:41 | * | a__b__m joined #nim |
| 14:09:41 | FromGitter | <mratsim> How does java deal with windows 256 characters limit in path if they reflect the dir structure? Java projects tend to have a crazily nested hierarchy |
| 14:10:01 | FromGitter | <yglukhov> I don't want you to implement this feature, I want you to to stop justifying the lack of it :) |
| 14:10:19 | Araq | no, tell me how to implement it and 0.20 will have it |
| 14:10:23 | FromGitter | <mratsim> Cargo/rust use the cargo.toml position as the project root |
| 14:11:12 | FromGitter | <mratsim> assuming you use cargo build, this is reasonable, if you use rustc directly, project root is the source file (not the working directory) |
| 14:12:07 | FromGitter | <mratsim> Caveat: when I started Rust I was absolutely confused how to import a file in the same directory |
| 14:12:38 | Araq | mratsim: that limit is not necessarily 256 but indeed some Java projects simply don't build on Windows. Been there, tried that. |
| 14:13:12 | * | a_b_m quit (Ping timeout: 244 seconds) |
| 14:14:52 | Araq | mratsim: I could use the .nimble file if it exists and then go up until I find one. And if I don't find any, ignore the first 3 dirs which likely are something like /home/<user>/stuff |
| 14:14:53 | FromGitter | <yglukhov> speaking of path length limitation. if it worked for the source files in the first place, it will most likely work for nimcache, because nimcache paths will most likely be shorter :) |
| 14:15:43 | FromGitter | <mratsim> Rust only uses the cargo.toml if used with cargo, otherwise it's the file passed as argument. |
| 14:16:15 | Araq | that sucks a bit though as 'nimble c' and 'nim c' are usually interchangable |
| 14:16:15 | FromGitter | <mratsim> but Cargo was designed from scratch to handle complex project and the rustc compiler was to be used sparingly |
| 14:17:20 | FromGitter | <mratsim> checking the directory ups in the filesystem might trip some security or sandboxing measures, I wouldn't recommend it. |
| 14:18:36 | FromGitter | <mratsim> Since it's a project/package issue it should be handled at the package manager level |
| 14:18:55 | FromGitter | <yglukhov> doesn't nim already do that? :) |
| 14:19:24 | FromGitter | <mratsim> the compiler should have a setRootDir/path option and the package manager should handle the magic and pass the proper path to the compiler |
| 14:20:35 | FromGitter | <yglukhov> i'm not a fan of package-manager-centric philosophy tbh. imo the compiler should be clever enough by its own |
| 14:23:19 | FromGitter | <mratsim> It's a separation of concerns. A tool that does one thing well: parsing, semcheck, building a binary. And one tool that does the complex project management well as well. |
| 14:24:08 | FromGitter | <mratsim> my main issues with naming is when vedoring multiple C projects |
| 14:24:18 | FromGitter | <mratsim> vendoring* |
| 14:25:23 | FromGitter | <mratsim> you get multiple C files with potentially conflicting names (main, tools, utils), and you might have to do silly workarounds for that. |
| 14:25:25 | FromGitter | <yglukhov> kinda yeah. but my point is that the compiler should be as close to the *default* way of package management as possible, still allowing to fallback to a different way. |
| 14:25:57 | FromGitter | <yglukhov> anyways, that's a topic orthogonal to duplicate file names :) |
| 14:27:52 | shashlick | Araq: sorry I had to drop earlier |
| 14:28:33 | shashlick | https://github.com/nim-lang/nimble/pull/635 is ready for review |
| 14:28:53 | * | i7sDream is now known as i8sDream |
| 14:29:00 | shashlick | Not sure what you meant by what's working |
| 14:29:17 | * | i8sDream is now known as i7sDream |
| 14:29:51 | FromGitter | <yglukhov> oh, btw. why "remove" compiler dependency from nimble? it feels like potentially less optimized way of parsing nimble files. might be relevant in... wait for it... complex projects :) |
| 14:31:07 | shashlick | Well it prevents having an older version of the compiler embedded in nimble that needs separate maintenance |
| 14:31:54 | shashlick | Plus shows nimble to evolve independently |
| 14:31:59 | shashlick | Allows |
| 14:33:34 | shashlick | The PR is testing the code with stable and devel, so in the future you could update nimble like pip while keeping the compiler stable |
| 14:35:04 | shashlick | Last, Araq wants to compile nimble files instead of using nimscript which will be a trivial next step from this pr |
| 14:35:22 | FromGitter | <yglukhov> ok, i see... |
| 14:36:18 | shashlick | Many more advantages, I can go on, but quick list |
| 14:37:57 | shashlick | Also it's still fast since most nimble functions are compiled in, only reading the package info, hooks and custom tasks need the vm |
| 14:38:45 | Araq | "A tool that does one thing well: parsing, semcheck, building a binary" that's 3 things and that's also why there is no science involved in these claims. |
| 14:39:22 | Araq | but it reads nice when put into a brochure. |
| 14:41:12 | * | Perkol joined #nim |
| 14:42:35 | FromGitter | <mratsim> that's compiling |
| 14:45:43 | FromGitter | <yglukhov> nimble + nim = building :) |
| 14:48:36 | FromGitter | <mratsim> a project* |
| 14:50:30 | shashlick | @dom96 did you see the choosenim binaries I posted? |
| 14:57:05 | FromDiscord | <SirBroadwell> please react with https://forum.nim-lang.org/t/4799 |
| 14:57:22 | FromGitter | <yglukhov> Araq: so to summarize. filename duplication would involve a notion of package root (which already exists), src structure replication in nimcache, init-functions names to include paths, (maybe) symbol hashing. Did I miss anything? |
| 15:02:32 | FromGitter | <mratsim> @SirBroadwell, @narimiran was hired for all of that in January :p |
| 15:05:51 | * | sz0 quit (Quit: Connection closed for inactivity) |
| 15:10:22 | * | rnrwashere joined #nim |
| 15:14:06 | * | jjido joined #nim |
| 15:17:07 | * | solitudesf joined #nim |
| 15:17:45 | FromGitter | <kaushalmodi> I am having a hard time using the dynlib pragma with exportc |
| 15:17:58 | FromGitter | <kaushalmodi> it is hard-coding my $USER in the .so reference |
| 15:18:12 | FromGitter | <kaushalmodi> so other users in my team are seeing a failure |
| 15:18:28 | FromGitter | <kaushalmodi> our flow involves using precompiled .so files from a central place |
| 15:19:20 | FromGitter | <kaushalmodi> as I compile those, it contains hard-coded references to the .so file even when I have `dynlib: ".." / "foo" / "bar.so"` |
| 15:19:23 | * | floppydh quit (Quit: WeeChat 2.4) |
| 15:19:50 | FromGitter | <mratsim> what if you use {.link: " ..." .} instead? |
| 15:20:18 | FromGitter | <kaushalmodi> so, just replace dynlib with link? |
| 15:21:49 | FromGitter | <kaushalmodi> .. and I meant `importc`, not `exportc` |
| 15:22:53 | shashlick | why are you giving a path, should't it be found with ldpath |
| 15:23:48 | FromGitter | <mratsim> I use link like this, I had issues with dynlib hardcoded path as well here: https://github.com/numforge/agent-smith/blob/master/third_party/ale_wrap.nim#L36-L58 |
| 15:24:18 | FromGitter | <kaushalmodi> shashlick: I need to figure out how to do that |
| 15:24:32 | shashlick | most nim examples i've seen just give so file without any path |
| 15:24:34 | FromGitter | <kaushalmodi> for now, I am creating a symlink in linux to the .so in the same dir at the .nim |
| 15:24:42 | shashlick | https://github.com/nim-lang/Nim/blob/devel/lib/wrappers/pcre.nim#L311 |
| 15:24:50 | FromGitter | <kaushalmodi> that works locally.. let's see if Jenkins likes it |
| 15:25:41 | shashlick | https://github.com/genotrance/nimbass/blob/master/nimbass.nimble#L18 is how i did it with bass.so |
| 15:29:15 | * | rnrwashere quit (Remote host closed the connection) |
| 15:29:47 | * | rnrwashere joined #nim |
| 15:31:18 | shashlick | i tried building nim in armv6 last night but csources build failed |
| 15:31:23 | * | mosORadi joined #nim |
| 15:36:48 | shashlick | /usr/bin/arm-linux-gnueabihf-ld: c_code/2_1/stdlib_io.o: undefined reference to symbol 'fflush@@GLIBC_2.4' |
| 15:36:54 | shashlick | this is on dockcross |
| 15:37:16 | * | rnrwashere quit (Remote host closed the connection) |
| 15:39:24 | FromGitter | <Varriount> shashlick: Sounds like the C compiler isn't linking in glibc object files |
| 15:43:47 | Araq | yglukhov: no, it's too much, all it takes is to change internally how we name the "fake nimble" packages |
| 15:44:25 | Araq | it should be pretty easy to change once we figured out how to determine these names |
| 15:44:41 | FromGitter | <kaushalmodi> shashlick: Setting LD_LIBRARY_PATH fixed it. Thanks |
| 15:49:53 | FromGitter | <kaushalmodi> there was another way without setting LD_LIBRARY_PATH, using some pragma within the Nim code |
| 15:49:54 | shashlick | which so is fflush in? -ldl is already in the command line |
| 15:55:05 | * | Tyresc joined #nim |
| 16:17:31 | * | Trustable joined #nim |
| 16:19:04 | leorize | shashlick: libc.so |
| 16:22:51 | * | Perkol quit (Remote host closed the connection) |
| 16:28:19 | shashlick | Shouldn't that get linked automatically? |
| 16:28:31 | shashlick | Do you have to specify -lc? |
| 16:29:23 | shashlick | Unless csources are looking for glibc2. 4 and there's an older version in this container |
| 16:37:17 | leorize | yea, it's usually linked automatically |
| 16:38:17 | leorize | try running `nm -D /path/to/libc.so | grep fflush@GLIBC` and see if the linked libc provides it |
| 16:41:21 | * | smitop joined #nim |
| 16:42:27 | smitop | https://www.irccloud.com/pastebin/mZUJJRXd/ |
| 16:42:31 | smitop | How is that erroring? |
| 16:43:04 | smitop | `bug.nim(10, 6) Error: '$' can have side effects` |
| 16:43:17 | smitop | But I can't see how `$` has side effects |
| 16:45:40 | shashlick | Thanks will try |
| 16:47:22 | xace | jesus smitop Tx is very confusing for my eyes |
| 16:47:48 | xace | isn't echo the problem? |
| 16:48:35 | smitop | Yep, that line is what calls the function causing the error |
| 16:48:42 | smitop | @xace |
| 16:49:24 | leorize | smitop: looks like `some` have side effects, somehow |
| 16:52:51 | leorize | the compiler should point out where exactly the side effects are, maybe worth a bug report |
| 16:53:01 | FromGitter | <jrfondren> even if you pull that out and say tx.prevTx == secret, it has side effects |
| 16:58:17 | * | a__b__m quit (Ping timeout: 268 seconds) |
| 17:02:04 | FromGitter | <arnetheduck> I |
| 17:02:17 | FromGitter | <jrfondren> options.get can throw exceptions |
| 17:06:34 | FromGitter | <arnetheduck> so the problem at hand is to determine the package root. a simple solution would be to add a directive in the file that tells it what package it's part of.. `package std` or whatever. |
| 17:10:57 | FromGitter | <arnetheduck> but tbh, I haven't thought it through that much.. I only note that the defaults in the language as they are now are poorly optimized for collaborative development.. they don't promote easy reuse of other people's code, and don't protect from things that patently are bad ideas as the project grows.. conceptually, it's the same situation as with mutable globals - I write some scripty code today and it kind of works at |
| 17:10:57 | FromGitter | ... the tiny scale, but it comes back to bite me as soon as I want to go multihtreaded (in 2019!!) or multi-module... if I look at some random nim code on github, chances are exceedingly high that it's not suitable for multithreading etc, and therefore cannot be reused. |
| 17:12:18 | FromGitter | <mratsim> I think we should write a post about our difficulty at using Nim at a larger scale, contrasting that with other compiled language approach like Go or Rust. |
| 17:12:38 | FromGitter | <jrfondren> wheels that aren't kicked will be discovered to be flat. |
| 17:15:09 | FromGitter | <arnetheduck> sure, though you know, we can find tweaks and workarounds and so on for specific issues - these are issues however that I think need addressing at a holistic level so that whatever the solution is, it "fits" well with the rest |
| 17:16:30 | FromGitter | <arnetheduck> maybe the focus of nim isn't to be good at collaborative development - I have no idea :) |
| 17:16:53 | shashlick | Well I'm in a small bubble but even when I was working on a large project, you cannot envision everything up front |
| 17:17:08 | shashlick | Some rearchitecture is inevitable |
| 17:18:09 | shashlick | But I am curious about specific instances where something didn't work - at least I relate better with examples |
| 17:18:17 | FromGitter | <arnetheduck> shashlick - that depends - if the language promotes good defaults, the amount of rearchitecture goes down / I can trust random code to be likely not to exhibit the bad practices |
| 17:20:03 | shashlick | Defaults are a cage, you will want to go out eventually and every instance will push the envelope further |
| 17:20:07 | FromGitter | <arnetheduck> sure. `gcsafe` is a trivial one - by default, nim code is mutable, global and thread-unsfae, and you have to go out of your way to avoid it (remember to use `let`, `func` etc - even though they're not extensively used in std lib and other random nim code you copypaste from. |
| 17:21:46 | FromGitter | <arnetheduck> no, defaults are defaults. they guide what you do *when you're not thinking about that particular aspect of the code*... ie when you're busy with the business logic, the defaults are what prevent you from shooting yourself in the foot. a good language (in my eyes) will then allow you to escape the defaults and do what's necessary in those exceptional situations that demand it |
| 17:22:12 | FromGitter | <jrfondren> as an alternative to smart import, you could have some slim windows to your large modules that import the large module and then only re-export smaller sections of it. these would need to tediously except all the stuff they don't want, but at least that's somewhat hidden. |
| 17:25:10 | * | rnrwashere joined #nim |
| 17:28:28 | FromGitter | <jrfondren> you can find your mutable globals and add {.threadvar.} to them. the reverse of what I'm used to (adding something like {.sharedvar.} selectively) |
| 17:28:33 | shashlick | Well you can end up with a Haskell situation where mutability becomes a nightmare |
| 17:30:03 | shashlick | But that sounds like a fundamental thing with Nim |
| 17:30:14 | shashlick | How do you propose dealing with that |
| 17:30:39 | shashlick | And how do rust or go help with that? |
| 17:34:09 | FromGitter | <mratsim> mutability being a nightmare is a feature in Haskell |
| 17:34:25 | FromGitter | <mratsim> then you have to explain beginners how to read and write into a file |
| 17:35:33 | FromGitter | <mratsim> Rust and go has reference approaches on imports for large collaborative codebases. |
| 17:37:47 | FromGitter | <arnetheduck> @jrfondren that's exactly what I'm talking about - if I have to make an extra effort to make my code thread safe, I won't first time around, because all my attention is focused on the business logic of the actual problem I'm trying to solve. thus I'll use whatever the language promotes without even thinking about it.. if the language promotes practices that are good for small-scale scripting / solo development, |
| 17:37:48 | FromGitter | ... that's the kind of nim code that will be most prevalent - it's really that simple.. |
| 17:38:11 | * | nsf quit (Quit: WeeChat 2.4) |
| 17:39:37 | FromGitter | <arnetheduck> `c` is like this too - it's easy to write code plagued by security holes and memory corruption, and that's simply what happens |
| 17:41:08 | * | mosORadi quit (Quit: Connection closed for inactivity) |
| 17:43:39 | FromGitter | <mratsim> as long as we don't get the inverse in excess (i.e. Haskell/Rust) |
| 17:47:26 | disruptek | jrfondren: CountTable.sort() is fixed in devel. |
| 17:48:21 | FromGitter | <jrfondren> cool, ty |
| 17:50:36 | * | rnrwashere quit (Remote host closed the connection) |
| 17:50:42 | disruptek | the goal should not be to make bad dev practices hard, but rather to make good dev practices easy/default. |
| 17:51:18 | * | rnrwashere joined #nim |
| 17:53:52 | rayman22201 | Hey shashlick. I'm just getting back online. (Yay, timezones!) I sent you a pm on gitter. |
| 18:00:54 | rayman22201 | regarding name-space issues and large scale project management. I like the idea that the Unison language is trying. Every symbol in the global namespace is just a hash, and each user has their own database of hash -> name. It doesn't matter if you have "pkg a/util" and "pkg b/util", they have different hashes, and you can just call them what ever you want. And I can call them something completely different if I want. :-P |
| 18:01:29 | rayman22201 | It's a very radical, experimental, and untested approach though. |
| 18:02:11 | disruptek | where do you specify the binding, though? |
| 18:05:05 | * | rnrwashere quit (Remote host closed the connection) |
| 18:06:19 | rayman22201 | There has to be some kind of tool support to handle name conflicts. When you import a symbol you have to specify what name you want to give it. |
| 18:06:37 | rayman22201 | or maybe I don't understand your question? |
| 18:06:48 | * | neceve quit (Read error: Connection reset by peer) |
| 18:07:56 | FromGitter | <jrfondren> what you're describing of Unison just sounds like a boring implementation detail. What's the actual experience of using it? |
| 18:09:20 | rayman22201 | "boring" is relative. I think it's quite exciting :-P also, it's an entirely different design for symbol resolution. How is that "just and implementation detail"? |
| 18:10:29 | rayman22201 | that's like saying "functional programming" is just an "implementation detail". or "hashing" is an implementation detail... What hash algorithm you use is an implementation detail, "hashing" is the design. |
| 18:10:57 | FromGitter | <jrfondren> it's boring because it doesn't actually imply anything about the experience. |
| 18:11:17 | shashlick | @rayman22201 just replied on gitter |
| 18:12:04 | rayman22201 | It implies that you never have symbol name clashes that fail to compile like "pkg a/util" and "pkg b/util" |
| 18:12:19 | rayman22201 | that is a big difference to user experience. |
| 18:12:34 | FromGitter | <jrfondren> namespaces in Python are just hash tables. Common Lisp has symbol tables and symbols themselves may as well be hashes. Wordlists in Forth easily let you have multiple words that refer to the same code, etc. |
| 18:13:39 | FromGitter | <jrfondren> well the "duplicate utils in submodules" sounds like a bug in Nim rather than anything else |
| 18:14:32 | rayman22201 | some people think it's a bug. Araq thinks it is a feature. That is the core of this argument. |
| 18:15:17 | rayman22201 | The difference with Unison is two things: |
| 18:15:17 | rayman22201 | - the granularity of hashing. It's at the individual symbol level, not the module level |
| 18:15:17 | rayman22201 | - each user has their own unique name -> hash mapping |
| 18:15:31 | FromGitter | <mratsim> there is no conflict if they come from different modules. ⏎ ⏎ But we want a monorepo and Nim/Nimble lacks facilities for this |
| 18:16:01 | FromGitter | <mratsim> so at the moment we have a workaround with git submodules and makefiles |
| 18:17:02 | * | rnrwashere joined #nim |
| 18:19:05 | * | rnrwashere quit (Remote host closed the connection) |
| 18:19:19 | * | rnrwashere joined #nim |
| 18:21:17 | * | natrys joined #nim |
| 18:21:59 | FromGitter | <mratsim> Like top 1 obstacle, if we use a src/module1, src/module2, src/module3 hierarchy, and then include["src"] in a nimble file, the src folder disappear and all modules become top-level, it makes it very hard to keep in sync dev and deployment because paths are different |
| 18:22:39 | FromGitter | <mratsim> And even nimble is suffering from this: https://github.com/nim-lang/nimble/blob/ee4c0aef26ae50062fdf6336d2213db3a317aca7/nimble.nimble#L4-L9 |
| 18:23:17 | * | rnrwashere quit (Remote host closed the connection) |
| 18:23:49 | * | rnrwashere joined #nim |
| 18:26:48 | * | Cthalupa quit (Ping timeout: 246 seconds) |
| 18:27:48 | shashlick | @mratsim I think nimble should have created a pkgname sub folder so that modules are imported as pkgname/x |
| 18:28:00 | shashlick | So there's clarity on imports |
| 18:29:24 | * | Cthalupa joined #nim |
| 18:34:22 | Araq | rayman22201: I do think it is a feature but I also don't care enough to keep it. ;-) |
| 18:34:45 | rayman22201 | lol. fair enough |
| 18:35:12 | Araq | in fact, removing this limitation for 0.20 was on my todo and then it got cancelled due to time constraints, we really need to focus on the essentials |
| 18:35:55 | * | natrys quit (Quit: natrys) |
| 18:39:40 | Araq | mratsim: that nimble moves files around is a different problem IMO. |
| 18:40:58 | disruptek | i don't understand how what unison does is any different from `import foo as bar`. |
| 18:42:46 | disruptek | the problem with hashing on some apparently unique quality of the environment is that it creates an insurmountable hurdle for "i know what i'm doing" scenarios. |
| 18:43:18 | * | i7sDream_ joined #nim |
| 18:43:21 | * | i7sDream quit (Read error: Connection reset by peer) |
| 18:43:36 | disruptek | but, i'm still not convinced i understand the concept. :-P |
| 18:45:21 | * | couven92 quit (Ping timeout: 246 seconds) |
| 18:45:38 | Araq | oh the concept is simple, you hash stuff into a number and then you have the theoretical possibility of a hash clash so you can then write an article "how hashing does not SCALE" |
| 18:47:56 | disruptek | damnit, i already renamed all 3255 binaries in /usr/bin to their md5sums today to solve the "unix doesn't scale" problem. are you telling me that didn't solve the problem? |
| 18:48:05 | Araq | lol |
| 18:48:20 | disruptek | last time i take advice from #nim... :-P |
| 18:48:26 | rayman22201 | Might be worth moving into #nim-offtopic, since we are getting into a tangent discussion. Hashes work for git, and that seems to have scaled pretty well lol |
| 18:49:51 | Araq | you can can create commits that produce the same hash as some other commit and then use that to create an attack vector when somebody checks out a particular commit and then security is doomed and we're all gonna die |
| 18:52:13 | FromGitter | <mratsim> well git is using a better hash function than svn |
| 18:52:14 | rayman22201 | lol. *boom* |
| 18:53:34 | rayman22201 | The articles on Unison tend to ramble, but I think this one describes the UX they are going for decently: http://unisonweb.org/2015-06-12/editing.html |
| 18:56:20 | rayman22201 | the big point is that computers are better at creating unique names than humans, so lets use that. It's not perfect but it scales better than what we currently have. |
| 18:56:41 | rayman22201 | then just make tools for humans to read it easier. |
| 18:57:48 | rayman22201 | but anyway. Nim should probably just do what Araq said, and remove the top level module name limitation :-P |
| 18:58:16 | Araq | shashlick: so. Now I'm ready to discuss your awesome Nimble PR. |
| 18:58:23 | Araq | if you are still here. |
| 19:00:20 | * | iLiquid joined #nim |
| 19:03:30 | * | rnrwashere quit (Remote host closed the connection) |
| 19:09:09 | * | rnrwashere joined #nim |
| 19:11:36 | shashlick | I'm here |
| 19:11:43 | shashlick | But on the phone |
| 19:12:25 | Araq | ok, good enough I guess. So did you manage to fix the problematic Nimble packages? |
| 19:13:13 | shashlick | Yes I was putting an extra space which was treated as a separate file |
| 19:15:19 | shashlick | https://travis-ci.org/nim-lang/nimble/builds/521541638 |
| 19:15:34 | shashlick | Tests pass on stable and devel |
| 19:15:35 | shashlick | Linux and osx |
| 19:15:51 | shashlick | Windows tested locally |
| 19:15:57 | shashlick | But that is nimble tests |
| 19:16:12 | Araq | tested 'nimx' with it? |
| 19:16:24 | shashlick | I tested some packages but only locally |
| 19:24:07 | * | NimBot joined #nim |
| 19:26:09 | * | nsf joined #nim |
| 19:27:27 | * | kapil____ quit (Quit: Connection closed for inactivity) |
| 19:48:07 | * | ricardo_ joined #nim |
| 19:54:26 | * | ricardo_ is now known as [rg] |
| 20:04:03 | shashlick | Any big concerns with the implementation Araq? |
| 20:13:58 | * | rnrwashere quit (Remote host closed the connection) |
| 20:13:58 | * | iLiquid quit (Quit: iLiquid) |
| 20:14:31 | * | iLiquid joined #nim |
| 20:18:16 | * | jjido quit (Quit: Textual IRC Client: www.textualapp.com) |
| 20:18:18 | disruptek | shashlick is desperate for some positive feedback, people. he worked his ass off on this patch. :-) |
| 20:40:29 | Araq | shashlick: no. I'm still reviewing it |
| 20:40:55 | Araq | tomorrow I'll try your branch with my packages and then I'll fight on your side to push it through. |
| 20:42:07 | Zevv | 13:27 <@Araq> I'm on holidays |
| 20:42:44 | dom96 | I'm reviewing it too :) |
| 20:48:27 | * | Tyresc quit (Ping timeout: 244 seconds) |
| 20:50:09 | xace | in which version is `nim c -g` going to work? |
| 20:50:48 | FromGitter | <mratsim> what is nim c -g? |
| 20:51:04 | xace | mratsim: another way of saying --debugger:native |
| 20:51:25 | FromGitter | <mratsim> somehow I guessed that :p |
| 20:51:41 | FromGitter | <mratsim> if it's merged in devel it will be for 0.20 |
| 20:51:54 | xace | i remember hearing about it, forgot where though... i'll use --debugger:native for now and change it sometime in the future, tho -g would be badass |
| 20:59:38 | Araq | will be in 0.20 |
| 20:59:44 | shashlick | Thanks folks :) |
| 21:00:46 | shashlick | I can then port this to nawabs as well if there's interest |
| 21:00:50 | shashlick | Where do nawabs and nimble intersect |
| 21:01:27 | xace | Oki. btw what are the limitations for nim module names? "my-prog.nim" results in Error: invalid module name |
| 21:02:22 | Araq | shashlick: better would be to add nawabs's ideas to Nimble |
| 21:03:03 | Araq | xace: because you can use mymodule.name to access the name and 'my-prog' is not a valid Nim identifier |
| 21:03:58 | Araq | for file in walkFiles(d / "*.babel"): # dom96 |
| 21:04:14 | Araq | can I remove that? there shouldn't be any .babel files around, right? |
| 21:04:28 | xace | Araq: oh, i see. you are right |
| 21:04:39 | * | Vladar quit (Remote host closed the connection) |
| 21:07:48 | * | Trustable quit (Remote host closed the connection) |
| 21:21:27 | * | xet7 quit (Ping timeout: 240 seconds) |
| 21:33:53 | * | xet7 joined #nim |
| 21:41:05 | FromGitter | <kaushalmodi> I am facing a problem using a local Nim library that I use in both: compiling using --app:lib to .so and to an executable |
| 21:41:33 | FromGitter | <kaushalmodi> when compiling to the executable, I get error like ⏎ ⏎ > file_ops.c:(.text+0x67d): undefined reference to `svGetArrElemPtr1' |
| 21:41:52 | FromGitter | <kaushalmodi> but I don't get any error if I compile that to a .so |
| 21:42:27 | FromGitter | <kaushalmodi> and if I remove that {.exportc.} tag, the executable compiles fine |
| 21:43:06 | Araq | does the exe import the .so? |
| 21:43:30 | FromGitter | <kaushalmodi> no |
| 21:44:01 | FromGitter | <kaushalmodi> The `svGetArrElemPtr1` fn is defined somewhere in the SystemVerilog compiler runtime |
| 21:44:27 | FromGitter | <kaushalmodi> I don't need that in the exe; only in the .so (which I use with SystemVerilog compiler) |
| 21:46:12 | FromGitter | <kaushalmodi> so I am expecting for nim to not worry about svGetArrElemPtr1 when I am compiling to a binary |
| 21:46:17 | FromGitter | <kaushalmodi> Is there any way to do that? |
| 21:47:24 | Araq | svGetArrElemPtr1 is used in file_ops.c/.nim |
| 21:47:35 | Araq | how could the compiler "not worry" about it? |
| 21:48:07 | FromGitter | <kaushalmodi> :) I know .. But only I know that I am not going to call that fn using the svGetArrElemPtr1 |
| 21:48:39 | FromGitter | <kaushalmodi> the SystemVerilog compiler tool contains 3.7k .so files |
| 21:48:46 | Araq | when appType == "lib": |
| 21:48:52 | FromGitter | <kaushalmodi> ah! |
| 21:48:53 | FromGitter | <kaushalmodi> perfect |
| 21:48:55 | Araq | proc ... |
| 21:49:02 | FromGitter | <kaushalmodi> let me try |
| 21:50:35 | * | solitudesf quit (Ping timeout: 268 seconds) |
| 21:51:41 | FromGitter | <kaushalmodi> works! (took me a while to revert everything I was messing around to try to understand this error :)) |
| 21:51:56 | FromGitter | <kaushalmodi> thanks |
| 21:57:10 | * | nsf quit (Quit: WeeChat 2.4) |
| 22:03:41 | * | Tyresc joined #nim |
| 22:07:28 | * | iLiquid quit (Quit: iLiquid) |
| 22:13:52 | * | [rg] quit (Quit: Leaving) |
| 22:23:10 | * | [rg] joined #nim |
| 22:23:48 | * | [rg] quit (Client Quit) |
| 22:23:57 | * | [rg] joined #nim |
| 22:32:02 | FromGitter | <jrfondren> not too familiar with github etiquette. Should I create an issue as well for https://github.com/zevv/npeg/pull/4 ? it's a straightforward bug fix, basically a typo. |
| 22:40:45 | Araq | just create a pr# |
| 22:41:12 | FromGitter | <jrfondren> cool. |
| 22:41:32 | * | lritter quit (Quit: Leaving) |
| 22:43:05 | * | stefanos82 quit (Remote host closed the connection) |
| 22:52:01 | disruptek | Error: target STRING not available |
| 22:52:16 | disruptek | er, Error: target STRING not available |
| 22:52:22 | disruptek | doh. damn c+p |
| 22:52:40 | disruptek | how can i track down what is producing a ProveInit warning? |
| 22:57:57 | * | smitop quit (Quit: Connection closed for inactivity) |
| 23:00:08 | * | chickendan quit (Quit: Quit) |
| 23:34:00 | * | [rg] quit (Quit: Leaving) |
| 23:43:24 | Araq | https://github.com/nim-lang/Nim/pull/11064 tada |
| 23:44:51 | * | chimez joined #nim |
| 23:46:15 | * | disruptek claps. |
| 23:46:20 | * | chimez quit (Client Quit) |
| 23:46:46 | disruptek | i like the `when false:`. something i've added to my code since nim. :-) |
| 23:55:55 | * | rnrwashere joined #nim |