| 00:05:31 | * | Trustable quit (Remote host closed the connection) |
| 00:15:36 | * | bjz quit (Ping timeout: 240 seconds) |
| 00:16:06 | * | bjz joined #nim |
| 00:20:42 | * | Vladar quit (Quit: Leaving) |
| 00:36:29 | * | adeohluwa joined #nim |
| 00:38:08 | * | libman joined #nim |
| 00:44:12 | * | bjz quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 00:48:45 | * | bjz joined #nim |
| 00:52:11 | * | vlad1777d quit (Quit: Leaving) |
| 00:56:01 | * | bjz quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 01:04:35 | * | chemist69 quit (Ping timeout: 256 seconds) |
| 01:06:07 | * | bjz joined #nim |
| 01:07:24 | * | libman quit (Ping timeout: 240 seconds) |
| 01:12:29 | * | libman joined #nim |
| 01:16:58 | * | libman quit (Ping timeout: 248 seconds) |
| 01:19:56 | * | adeohluwa quit (Remote host closed the connection) |
| 01:21:42 | * | libman joined #nim |
| 01:27:15 | * | kunev quit (Ping timeout: 252 seconds) |
| 01:28:29 | * | kunev joined #nim |
| 01:30:23 | * | handlex joined #nim |
| 01:31:39 | * | chemist69 joined #nim |
| 01:33:06 | * | handlex quit (Client Quit) |
| 01:45:31 | FromGitter | <timeyyy> Ha |
| 01:46:16 | FromGitter | <timeyyy> You can use an else with for in python |
| 01:46:19 | * | couven92 quit (Read error: Connection reset by peer) |
| 02:04:55 | * | eizua joined #nim |
| 02:27:40 | * | chemist69 quit (Ping timeout: 240 seconds) |
| 02:41:49 | * | chemist69 joined #nim |
| 03:10:05 | * | Snircle quit (Ping timeout: 255 seconds) |
| 03:22:32 | * | dddddd quit (Remote host closed the connection) |
| 03:33:36 | * | rtr_ quit (Remote host closed the connection) |
| 03:35:26 | * | Snircle joined #nim |
| 03:43:14 | * | Snircle quit (Quit: Textual IRC Client: www.textualapp.com) |
| 04:05:40 | * | libman quit (Ping timeout: 240 seconds) |
| 04:06:06 | FromGitter | <Varriount> @timeyyy I use that occasionally. |
| 04:07:30 | * | rtr_ joined #nim |
| 04:07:43 | FromGitter | <zacharycarter> Hi - I'm trying to wrap a C header file with nim and I'm running into some errors I'm not sure how to solve. I've created a gist with the header file, nim file created by c2nim, and an error log - https://gist.github.com/zacharycarter/5f49108595fee8437a82ae78a0f614c2 |
| 04:10:42 | * | libman joined #nim |
| 04:15:13 | FromGitter | <zacharycarter> not sure how to mix two bitmasks :/ |
| 04:20:20 | Araq | zacharycarter: you need to modify the 'enum' definitions so that they produce valid Nim enums |
| 04:20:28 | Araq | usually this means something like |
| 04:21:46 | Araq | enum nk_widget_states { |
| 04:21:46 | Araq | NK_WIDGET_STATE_MODIFIED = (1 << (1)), |
| 04:21:46 | Araq | NK_WIDGET_STATE_INACTIVE = (1 << (2)), |
| 04:21:48 | Araq | NK_WIDGET_STATE_ENTERED = (1 << (3)), |
| 04:21:50 | Araq | NK_WIDGET_STATE_HOVER = (1 << (4)), |
| 04:21:52 | Araq | NK_WIDGET_STATE_ACTIVED = (1 << (5)), |
| 04:21:54 | Araq | NK_WIDGET_STATE_LEFT = (1 << (6)) |
| 04:21:56 | Araq | }; |
| 04:22:18 | FromGitter | <zacharycarter> gotcha thank you @Araq |
| 04:23:14 | Araq | #define NK_WIDGET_STATE_HOVERED = orflags(NK_WIDGET_STATE_HOVER|NK_WIDGET_STATE_MODIFIED) |
| 04:23:28 | Araq | then have something like |
| 04:24:08 | Araq | template orflags(a, b): untyped = type(a)(a.cint or b.cint) |
| 04:24:34 | Araq | I mean |
| 04:25:02 | Araq | #define NK_WIDGET_STATE_HOVERED = orflags(NK_WIDGET_STATE_HOVER, NK_WIDGET_STATE_MODIFIED) |
| 04:25:23 | Araq | http://nim-lang.org/docs/c2nim.html#embedding-nim-code |
| 04:25:42 | Araq | you can have this template definition in the C code :-) |
| 04:26:10 | FromGitter | <zacharycarter> okay awesome thank you :) I'll give that a shot |
| 04:26:54 | Araq | the goal should always be to modify the header file so that it produces a Nim file that must not be modified at all |
| 04:26:57 | * | eizua quit (Remote host closed the connection) |
| 04:27:11 | FromGitter | <zacharycarter> gotcha |
| 04:27:29 | Araq | so that you can diff & patch against a new version of the header file easily |
| 04:28:56 | FromGitter | <zacharycarter> makes sense |
| 04:29:39 | * | chemist69 quit (Ping timeout: 276 seconds) |
| 04:31:30 | * | chemist69 joined #nim |
| 04:37:20 | * | arnetheduck quit (Ping timeout: 245 seconds) |
| 04:48:11 | * | rtr_ quit (Quit: Leaving...) |
| 04:57:13 | FromGitter | <Varriount> And now for something different: https://www.youtube.com/watch?v=hHRy-gA9rTU |
| 05:03:02 | * | abruanese quit (Read error: Connection reset by peer) |
| 05:08:13 | * | brson quit (Quit: leaving) |
| 05:26:37 | * | bjz quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 05:48:47 | * | bjz joined #nim |
| 06:34:42 | * | chemist69 quit (Ping timeout: 252 seconds) |
| 06:35:18 | * | chemist69 joined #nim |
| 07:04:05 | Araq | https://github.com/nim-lang/ui |
| 07:04:10 | Araq | high level wrapper has arrived |
| 07:53:47 | libman | Yaaay! |
| 07:56:41 | * | Sembei joined #nim |
| 08:02:32 | libman | (Although it's really just a GTK wrapper, right? No reason for me to get too excited.) |
| 08:08:00 | * | rokups joined #nim |
| 08:12:01 | * | libman quit (Ping timeout: 255 seconds) |
| 08:15:51 | * | Kingsquee quit (Quit: https://i.imgur.com/qicT3GK.gif) |
| 08:17:17 | * | bjz quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 08:23:11 | * | Sembei quit (Ping timeout: 256 seconds) |
| 08:28:44 | * | bjz joined #nim |
| 08:48:10 | FromGitter | <Varriount> libman: It's not a GTK wrapper (or at least not directly) it uses LonG I |
| 08:48:18 | FromGitter | <Varriount> *libui |
| 08:56:49 | * | Trustable joined #nim |
| 09:13:08 | * | yglukhov joined #nim |
| 09:13:32 | * | yglukhov quit (Remote host closed the connection) |
| 09:15:28 | * | yglukhov joined #nim |
| 09:19:31 | * | yglukhov quit (Ping timeout: 240 seconds) |
| 09:22:31 | * | GustavoLapasta joined #nim |
| 09:30:55 | * | yglukhov joined #nim |
| 09:51:13 | * | yglukhov quit (Remote host closed the connection) |
| 09:58:35 | * | Vladar joined #nim |
| 10:12:53 | * | yglukhov joined #nim |
| 10:13:39 | * | yglukhov quit (Remote host closed the connection) |
| 10:14:16 | * | yglukhov joined #nim |
| 10:16:51 | FromGitter | <timeyyy> One issue left in the roadmap for 1.0! |
| 10:16:58 | FromGitter | <ephja> it wouldn't be very suitable as an official candidate had it only supported GTK |
| 10:18:24 | * | yglukhov quit (Ping timeout: 240 seconds) |
| 10:22:13 | FromGitter | <ephja> I'm sure many people appreciate such an addition. the various low level bindings that we have are tedious to use. I like nimx since it also supports js/canvas, but it's still in development and might not ever have a particularly native look |
| 10:34:34 | dom96 | Araq: no readme? |
| 10:35:14 | dom96 | lol https://github.com/nim-lang/ui/pull/1/files |
| 10:35:17 | dom96 | I totally forgot I made this |
| 10:44:07 | * | yglukhov joined #nim |
| 10:44:42 | * | Kingsquee joined #nim |
| 10:46:10 | * | Salewski joined #nim |
| 10:46:32 | Salewski | > high level wrapper has arrived |
| 10:47:09 | Salewski | Great. I will look at it to learn how high level part is done! |
| 10:47:31 | Salewski | Will you use it for your NimEdit? |
| 10:49:22 | cheatfate | Salewski, NimEdit is closed source Araq's product |
| 10:49:30 | Salewski | And for NimEdit, there was someone complaining about missing docs, maybe someone should do a short reply: http://forum.nim-lang.org/t/1950 |
| 10:50:03 | Salewski | cheatfate, Araq said he will open it this year! |
| 10:50:30 | cheatfate | Salewski, currently its totally unusable because of font rendering... |
| 10:50:45 | cheatfate | i dont know how Araq is using it |
| 10:51:06 | cheatfate | maybe he has some kind of glasses which sharpens weird fonts he uses in NimEdit |
| 10:51:25 | Salewski | I know, and Araq has not advertised it. But answering forum posts may be a good idea. |
| 10:53:26 | dom96 | I doubt libui has enough features for an IDE |
| 10:54:01 | * | bjz quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 10:54:22 | dom96 | I think an Electron for Nim would be extremely useful. |
| 10:55:40 | * | byte512 joined #nim |
| 10:56:30 | * | GustavoLapasta quit (Ping timeout: 252 seconds) |
| 11:04:48 | cheatfate | dom96, i think you are missed something Electron is for javascript only, we need to integrate libCEF |
| 11:05:24 | dom96 | cheatfate: I am aware, I said "Electron for Nim" meaning "an electron-like library that works with Nim" |
| 11:11:07 | cheatfate | there is currently only one i think and this is libCEF |
| 11:13:24 | dom96 | yes, as far as I know Electron is built on libCEF |
| 11:16:16 | cheatfate | https://github.com/electron/electron/issues/1170 |
| 11:19:29 | * | nsf joined #nim |
| 11:19:54 | * | Salewski left #nim (#nim) |
| 11:24:51 | * | stisa joined #nim |
| 11:25:58 | federico3 | sounds like https://kivy.org/ |
| 11:35:46 | * | bjz joined #nim |
| 11:38:58 | cheatfate | federico3, i dont know kivy but looks like it not using browser to render graphics |
| 11:40:57 | federico3 | cheatfate: you mean stuff like WebGL. Besides, we are not leveraging the fact that Nim can produce both server and client-side code |
| 11:41:36 | cheatfate | federico3, i mean i dont need to make CSS and `createElement` to create button on screen |
| 11:42:39 | cheatfate | every application based on Electron and libCEF have size 100mb+ |
| 11:44:58 | cheatfate | also kivy is just user interface but electron and libcef has also cross-platform sound api |
| 11:45:16 | cheatfate | and video api |
| 11:56:39 | * | Pisuke quit (Quit: WeeChat 1.6-dev) |
| 12:01:32 | * | Snircle joined #nim |
| 12:04:09 | Araq | dom96: the only feature severely lacking is decent event handling |
| 12:04:27 | Araq | apart from that I could port NimEdit over to use libui |
| 12:05:15 | * | chemist69 quit (Ping timeout: 245 seconds) |
| 12:06:48 | dom96 | Araq: What's indecent about the current event handling? |
| 12:07:26 | * | yglukhov quit (Remote host closed the connection) |
| 12:07:26 | Araq | you cannot get keypresses as unicode |
| 12:08:06 | cheatfate | Araq, to transfer scancode to unicode you need a biiig library |
| 12:09:04 | dom96 | Araq: btw, you should move rawui.nim into a ui directory |
| 12:09:21 | * | Salewski joined #nim |
| 12:11:31 | Salewski | But libui is GTK3 on Linux, so people hating GTK will refuse to use it on Linux. I just remembered -- see last post in this thread: |
| 12:11:37 | Salewski | http://www.digitalmars.com/d/archives/digitalmars/D/announce/Dynamic_Bindings_to_libui_x-platform_GUI_43701.html |
| 12:12:19 | Salewski | What is state of QML? May that allow a Nim Qt IDE? |
| 12:13:36 | cheatfate | Salewski, i think QT adoptation is much harder then even adopt wayland or xcb |
| 12:14:37 | Salewski | Yes, Qt is very hard, but we have QML bindings. But I do know not much about it. |
| 12:15:22 | Araq | I always liked the GTK look&feel. it's just that the API sucks |
| 12:16:00 | cheatfate | if somebody will start pure nim ui library for macos, then i can help with windows and linux (xcb/wayland) |
| 12:16:42 | Araq | and "people hating GTK on Linux" ... well... so we lose 3 people on this planet. |
| 12:18:39 | Salewski | Araq, I have the strong feeling that most Linux users now hate GTK (I dont know really why, I use it still). |
| 12:18:57 | * | yglukhov joined #nim |
| 12:19:18 | Salewski | So a cross platform GUI with GTK on Linux will not attract new Linux users. |
| 12:19:20 | cheatfate | main problem of GTK is development of custom widgets... until you are using gtk widgets everything is fine, but if you need to build custom widget you are in troubles, there so many bugs and so poor documentation... i'm curious how gtksourceview appeared |
| 12:19:55 | Salewski | Cheatfate: very true. |
| 12:20:06 | Araq | custom widgets need putPixel and renderText as far as I'm concerned |
| 12:20:26 | * | GustavoLapasta joined #nim |
| 12:20:39 | Araq | but I don't know how GTK's canvas works |
| 12:21:26 | cheatfate | Araq, custom widgets needs events too... and when i have tried to make GTK3 hexedit widget using pygobject i have failed... |
| 12:22:16 | Salewski | Araq, for custom gtk widgets one can use the gobject object system, which is a bit hard. Drawing is easy using cairo lib. |
| 12:22:53 | Araq | either way, a cross platform GUI that uses X11 instead of GTK would be much worse |
| 12:23:03 | * | macbeth joined #nim |
| 12:23:04 | * | Kingsquee quit (Quit: https://i.imgur.com/qicT3GK.gif) |
| 12:23:05 | cheatfate | Araq, why? |
| 12:23:30 | Salewski | But it is not only GTK API, Ruby or Python GTK Api is not bad, it is really a high level API. I think C++ API is not bad too. |
| 12:23:45 | Araq | cheatfate: uglier, barbaric copy&paste shortcuts iirc |
| 12:23:45 | cheatfate | Salewski, pygobject is crap |
| 12:24:00 | Salewski | But no one is using Ruby GTK now. |
| 12:24:49 | cheatfate | Araq, you are wrong, and fast enough last time i checked... |
| 12:25:36 | Araq | and shouldn't we use Wayland instead of X11 now? |
| 12:25:45 | cheatfate | we need wayland backend too |
| 12:25:59 | macbeth | Hi! I'm an editor of Russian Wikipedia. I would like to improve the article about Nim. Should I do that? Or maybe it's better to wait 1.0 version? |
| 12:26:04 | cheatfate | and now i think we need Mir backend too |
| 12:26:46 | Araq | macbeth: no, do it right now. version 1.0 has no release date |
| 12:28:27 | Araq | заранее спасибо |
| 12:29:40 | cheatfate | lol |
| 12:32:31 | * | chemist69 joined #nim |
| 12:32:50 | macbeth | Thank you! So, the question is: should I only translate English article or am I welcomed to improvise? |
| 12:34:16 | * | yglukhov quit (Remote host closed the connection) |
| 12:34:44 | cheatfate | macbeth, do you want to add some propaganda to article about nim? |
| 12:34:50 | * | yglukhov joined #nim |
| 12:35:14 | Salewski | macbeth: maybe improve the english article first, when there is room for improvements? I once saw the french one, with some strange improvements... |
| 12:35:48 | * | couven92 joined #nim |
| 12:35:50 | macbeth | cheatfate: articles should be neutral) |
| 12:36:43 | macbeth | Salewski: that's why I asked about translation. I agree with you |
| 12:39:23 | * | yglukhov quit (Ping timeout: 264 seconds) |
| 12:42:38 | * | bjz_ joined #nim |
| 12:44:26 | * | bjz quit (Ping timeout: 248 seconds) |
| 12:47:30 | * | yglukhov joined #nim |
| 12:48:14 | * | hendi joined #nim |
| 12:49:10 | FromGitter | <Jeff-Ciesielski> @Araq : Thinking a bit about volatile load/volatile store. Do you have any thoughts on implementation? I put something together with emit+generic proc that works well enough, but it strikes me that it could also be done via some compiler magic (at a high level glance, attaching a new 'volatile load/store' flag to the TLoc object and checking for that during the emission phase of code gen) |
| 12:49:41 | FromGitter | <Jeff-Ciesielski> Second way seems more complex, but arguably 'better' since you omit the extra proc + stack frame associated with it |
| 12:50:21 | Araq | with 0.16.0 template+emit works |
| 12:50:26 | Araq | no calling overhead |
| 12:51:58 | FromGitter | <Jeff-Ciesielski> That was my initial thought and I tried to get it working, but kept running into type related issues |
| 12:52:23 | FromGitter | <Jeff-Ciesielski> I'll give it another shot |
| 12:53:01 | Araq | the last thing we need is a volatile concept in the codegen |
| 12:54:19 | FromGitter | <Jeff-Ciesielski> I don't disagree, I want to keep this simple and try to do it in the standard library if possible |
| 12:54:29 | FromGitter | <Jeff-Ciesielski> The number of people that really need this is probably very low |
| 12:55:42 | cheatfate | Araq, i want to have int128 :) |
| 13:03:37 | * | Snircle quit (Ping timeout: 255 seconds) |
| 13:03:53 | Salewski | Yes, int128 would be nice. But I do not really need it. |
| 13:05:20 | Araq | use a bignum instead? |
| 13:06:33 | cheatfate | Araq, i have already my own bignum, but it needs int128 to be faster :) |
| 13:07:36 | cheatfate | last time i have asked def- about his bignum he told me it 5x slower then gmp, and if we get int128 i think we will be near equal in speed with gmp |
| 13:13:29 | Araq | can't we beat it in practice thanks to our term rewriting macros? |
| 13:18:04 | cheatfate | gmp uses XMM0–XMM15 to hold parts of bignum... and we are using Rxx |
| 13:18:16 | cheatfate | so they can mul/div much faster then we are |
| 13:23:59 | * | Snircle joined #nim |
| 13:24:44 | * | vlad1777d joined #nim |
| 13:27:22 | * | abruanese joined #nim |
| 13:32:39 | * | yglukhov quit (Remote host closed the connection) |
| 13:44:14 | * | yglukhov joined #nim |
| 13:45:48 | * | Snircle quit (Quit: Textual IRC Client: www.textualapp.com) |
| 13:46:34 | * | yglukhov quit (Remote host closed the connection) |
| 13:48:29 | * | yglukhov joined #nim |
| 13:57:07 | * | Snircle joined #nim |
| 14:01:17 | * | stisa quit (Ping timeout: 255 seconds) |
| 14:07:26 | * | yglukhov quit (Remote host closed the connection) |
| 14:11:31 | * | bjz_ quit (Ping timeout: 240 seconds) |
| 14:11:48 | * | bjz joined #nim |
| 14:15:57 | * | chemist69 quit (Ping timeout: 276 seconds) |
| 14:18:22 | * | chemist69 joined #nim |
| 14:34:50 | * | Sembei joined #nim |
| 14:37:28 | * | stisa joined #nim |
| 14:52:08 | FromGitter | <Varriount> Why can't we just use GMP? |
| 14:52:22 | FromGitter | <Varriount> Is it a licensing issue? |
| 14:55:41 | Araq | it's GNU, so yeah |
| 14:57:04 | * | Ven joined #nim |
| 15:02:40 | * | stisa quit (Ping timeout: 240 seconds) |
| 15:07:57 | * | yglukhov joined #nim |
| 15:12:20 | * | yglukhov quit (Ping timeout: 240 seconds) |
| 15:18:50 | chemist69 | `Araq: high level wrapper has arrived` - THANKS, Araq! I use this library a lot for writing cross-compiled small apps for Windows and with the high-level it will be even easier. |
| 15:19:47 | chemist69 | I will also have a look and try to learn how to write a high-level wrapper in Nim |
| 15:25:41 | * | Snircle quit (Quit: Textual IRC Client: www.textualapp.com) |
| 15:28:41 | * | bjz quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 15:51:58 | Calinou | Rust got i128 recently, it seems |
| 15:59:09 | * | MyMind joined #nim |
| 16:07:53 | * | yglukhov joined #nim |
| 16:15:31 | FromGitter | <zacharycarter> good morning |
| 16:15:56 | FromGitter | <zacharycarter> I have some code where I'm trying to call loadExtensions() from the opengl bindings |
| 16:16:49 | FromGitter | <zacharycarter> and I'm getting this error - https://gist.github.com/zacharycarter/7ac0e540c63aed33624e81508423e39e |
| 16:16:51 | * | stisa joined #nim |
| 16:17:27 | FromGitter | <zacharycarter> The strange thing is... I've successfully called this method before in the same project, just in a different source file |
| 16:18:07 | FromGitter | <zacharycarter> I've tried deleting the nimcache directory but that didn't help |
| 16:18:25 | FromGitter | <zacharycarter> not sure if it has to do with the fact that my .nimble file is one directory down |
| 16:19:31 | FromGitter | <zacharycarter> My directory layout looks like - ⏎ ⏎ / ⏎ dEngine ⏎ |_ ... [https://gitter.im/nim-lang/Nim?at=58838a12d43728124e873fdb] |
| 16:19:35 | FromGitter | <zacharycarter> oh that didn't work... |
| 16:19:44 | FromGitter | <zacharycarter> I'll add it to the gist... |
| 16:20:37 | FromGitter | <zacharycarter> okay gist updated |
| 16:25:47 | Araq | zacharycarter if you don't use extensions, you cannot call loadExtensions |
| 16:27:09 | niv | hello! quick question about `nim doc`: how can i get it to parse incldue statements, not just link import ones? |
| 16:27:37 | Araq | niv: 'nim doc2' |
| 16:27:40 | FromGitter | <zacharycarter> @Araq I'll look further into the docu on loadextensions, thank you |
| 16:28:26 | Araq | zacharycarter: the opengl wrapper should produce a dummy dependency to an extension so that loadExtensions always is available |
| 16:28:31 | Araq | you can create an issue for this |
| 16:29:11 | * | MyMind quit (Ping timeout: 264 seconds) |
| 16:29:37 | niv | ty, Araq |
| 16:30:09 | FromGitter | <zacharycarter> okay I will @Araq |
| 16:33:52 | * | Salewski left #nim (#nim) |
| 16:33:53 | niv | hmm .. except doc2 randomly skips a proc |
| 16:34:05 | FromGitter | <zacharycarter> @Araq - https://github.com/nim-lang/opengl/issues/39 |
| 16:34:44 | Araq | ty |
| 16:34:58 | FromGitter | <zacharycarter> np! |
| 16:35:07 | Araq | niv: nim's website uses doc2 extensively. are you sure it's not a missing export marker? |
| 16:35:37 | niv | actually, it skips a file i have included. that file contains a few *-marked procs |
| 16:35:42 | niv | they never show up in the aggregated doc |
| 16:35:53 | niv | they do show up in the individual file that was generated for the include though |
| 16:36:22 | * | MyMind joined #nim |
| 16:36:54 | niv | i was hoping to split up my code into multiple files because its getting a bit long. but all parts are kind of interdependent so i can only really use include, not split them into compilation units |
| 16:39:42 | * | couven92 quit (Read error: Connection reset by peer) |
| 16:45:33 | Araq | doc2 DOES handle include |
| 16:45:52 | niv | yes, im obviously doing something wrong. working on figuring out |
| 16:49:25 | dom96 | yay, Nim will be a part of the next TIOBE index. |
| 16:50:06 | federico3 | really? |
| 16:54:48 | * | vlad1777d quit (Remote host closed the connection) |
| 16:56:20 | * | pie_ joined #nim |
| 17:03:12 | dom96 | federico3: yep |
| 17:03:13 | * | stisa quit (Read error: Connection reset by peer) |
| 17:04:53 | * | MyMind quit (Max SendQ exceeded) |
| 17:06:58 | * | MyMind joined #nim |
| 17:13:57 | * | MyMind quit (Max SendQ exceeded) |
| 17:14:27 | * | stisa joined #nim |
| 17:16:56 | * | MyMind joined #nim |
| 17:20:09 | niv | Araq: sorry, can't figure it out. doc2 is skipping one proc that doc shows just fine. any hints on how to fix that? |
| 17:23:27 | Araq | report it |
| 17:29:00 | * | tinAndi joined #nim |
| 17:31:48 | * | hendi quit (Quit: hendi) |
| 17:33:06 | niv | okay, will try to make a repro case. |
| 17:34:09 | niv | style question: setField(v) or field=(v)? |
| 17:34:42 | Araq | field= |
| 17:34:52 | niv | thank you |
| 17:35:13 | * | irrequietus joined #nim |
| 17:45:03 | Araq | https://xkcd.com/936/ |
| 17:57:20 | * | irrequietus quit () |
| 18:00:00 | * | tinAndi quit (Ping timeout: 252 seconds) |
| 18:02:00 | * | tinAndi joined #nim |
| 18:05:11 | * | irrequietus joined #nim |
| 18:10:18 | * | irrequietus quit () |
| 18:12:32 | * | kulelu88 joined #nim |
| 18:12:43 | * | yglukhov quit (Remote host closed the connection) |
| 18:16:43 | * | tinAndi quit (Quit: ChatZilla 0.9.93 [Firefox 50.1.0/20161208153507]) |
| 18:25:25 | * | nsf quit (Quit: WeeChat 1.7) |
| 18:27:02 | * | MyMind quit (Read error: No route to host) |
| 18:34:40 | * | stisa quit (Read error: Connection reset by peer) |
| 18:41:50 | * | MyMind joined #nim |
| 18:43:23 | * | Sembei quit (Ping timeout: 240 seconds) |
| 18:57:33 | * | jjido joined #nim |
| 18:58:27 | * | yglukhov joined #nim |
| 19:00:42 | * | byte512 quit (Ping timeout: 256 seconds) |
| 19:01:20 | * | yglukhov quit (Remote host closed the connection) |
| 19:01:44 | * | yglukhov joined #nim |
| 19:03:12 | * | jjido quit (Read error: Connection reset by peer) |
| 19:03:50 | * | yglukhov quit (Remote host closed the connection) |
| 19:04:00 | * | jjido joined #nim |
| 19:04:58 | * | jjido quit (Read error: No route to host) |
| 19:05:39 | * | jjido joined #nim |
| 19:05:45 | * | yglukhov joined #nim |
| 19:07:25 | * | jjido quit (Remote host closed the connection) |
| 19:07:31 | * | macbeth quit (Quit: Connection closed for inactivity) |
| 19:07:47 | * | jjido joined #nim |
| 19:10:52 | * | Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 19:17:31 | * | jjido quit (Read error: Connection reset by peer) |
| 19:20:30 | * | gangstacat quit (Quit: Ĝis) |
| 19:21:15 | * | yglukhov quit (Remote host closed the connection) |
| 19:27:38 | * | nsf joined #nim |
| 19:27:41 | * | gangstacat joined #nim |
| 19:31:24 | * | yglukhov joined #nim |
| 19:34:47 | * | yglukhov quit (Remote host closed the connection) |
| 19:49:25 | * | yglukhov joined #nim |
| 19:53:24 | dom96 | This is pretty cool http://www.krihelinator.xyz/repositories/Nimrod |
| 20:01:30 | * | hendi joined #nim |
| 20:03:13 | Araq | yeah indeed. |
| 20:04:02 | Araq | I'm hacking together some new installer with downloader |
| 20:04:34 | Araq | and zipfiles+httpclient+libui+registry is a strong combo. |
| 20:05:20 | cheatfate | dont forget openssl wrapper |
| 20:05:23 | cheatfate | ^^ |
| 20:05:32 | cheatfate | Araq, dont forget openssl wrapper |
| 20:05:48 | Araq | pfff our website has no https |
| 20:06:45 | cheatfate | and this is bad... |
| 20:07:05 | Araq | yeah dom96 is working on it |
| 20:07:26 | cheatfate | so your installer will use zlib/openssl/zipfiles/httpclient/libui.dll/registry |
| 20:07:34 | dom96 | more like "it's on my to do list" |
| 20:07:38 | dom96 | I'm not actively working on it |
| 20:07:54 | cheatfate | a little bit overhead, dont you think so? |
| 20:10:00 | cheatfate | if your installer suited to work on windows you don't need httpclient/openssl/zipfiles/zlib |
| 20:10:52 | cheatfate | because windows has zip api and also has urldownloadtofile |
| 20:11:09 | cheatfate | which has ssl support inside |
| 20:11:46 | * | yglukhov quit (Remote host closed the connection) |
| 20:12:54 | * | yglukhov joined #nim |
| 20:14:40 | Araq | how come you know the Win API so well? |
| 20:18:18 | cheatfate | Araq, i'm pretty old windows programmer :) |
| 20:22:05 | * | rokups quit (Quit: Connection closed for inactivity) |
| 20:22:19 | cheatfate | also i have wasted many time on reverse engineering |
| 20:22:27 | cheatfate | of windows apps |
| 20:28:12 | * | libman joined #nim |
| 20:29:15 | dom96 | cheatfate: can you get progress status from that API? |
| 20:30:27 | * | GustavoLapasta quit (Quit: Leaving) |
| 20:32:09 | * | hendi quit (Quit: hendi) |
| 20:34:12 | cheatfate | dom96, please check https://msdn.microsoft.com/en-us/library/ms775123(v=vs.85).aspx |
| 20:34:18 | federico3 | https://developers.slashdot.org/story/17/01/21/0516219/new-release-of-nim-borrows-from-python-rust-go-and-lisp /. is still kinda-sorta alive |
| 20:34:48 | dom96 | federico3: cool, didn't realise we got slashdotted |
| 20:37:59 | cheatfate | how it happens nim is borrowed something if Nim is older then Rust??? |
| 20:38:21 | cheatfate | but anyway any advertising is good advertising |
| 20:38:33 | dom96 | yeah, the article is quite inaccurate |
| 20:43:04 | dom96 | https://developers.slashdot.org/comments.pl?sid=10146699&cid=53710793 |
| 20:43:15 | dom96 | Looks like it's time to swing the banhammer |
| 20:45:42 | dom96 | Reading these comments is painful |
| 20:45:55 | dom96 | No wonder I never look at SlashDot |
| 20:48:32 | * | dddddd joined #nim |
| 20:48:36 | cheatfate | dom96, 97 comments is good result anyway, somebody can capture troll's messages and put it there... |
| 20:50:07 | cheatfate | and say that we are here don't allow muslims to say anything |
| 20:50:19 | federico3 | slashdot, HN, reddit... they got to levels near 4chan in the last years |
| 20:50:21 | cheatfate | and banning them all the time |
| 20:50:38 | dom96 | https://developers.slashdot.org/comments.pl?sid=10146699&cid=53711585 |
| 20:50:42 | dom96 | Who could this be? |
| 20:50:57 | dom96 | HN and Reddit are far more mature than Slashdot |
| 20:51:59 | cheatfate | http://www.ischo.com |
| 20:52:29 | * | bjz joined #nim |
| 20:52:44 | cheatfate | dom96, do you know all persons here on channel? i think i dont know like 80% of people just sitting here and capturing our messages |
| 20:54:54 | cheatfate | maybe we need to make some kind of private channel to discuss, and here we can only answer questions, without disputes |
| 20:57:05 | dom96 | we have #nim-offtopic which isn't logged |
| 20:57:29 | dom96 | People can say whatever they want in this channel though |
| 20:57:55 | dom96 | I bet I can quote someone from #rust who was being offensive |
| 21:11:07 | * | plm joined #nim |
| 21:11:11 | plm | Hi all |
| 21:11:35 | plm | nim supports whats archs? |
| 21:13:14 | FromGitter | <yglukhov> plm: all of them |
| 21:13:29 | plm | FromGitter: I think not |
| 21:13:30 | FromGitter | plm, I'm a bot, *bleep, bloop*. I relay messages between here and https://gitter.im/nim-lang/Nim |
| 21:13:42 | plm | Linux (most, if not all, distributions) - x86, x86_64, ppc64 and armv6l |
| 21:13:45 | plm | "Linux (most, if not all, distributions) - x86, x86_64, ppc64 and armv6l" |
| 21:14:00 | plm | I would like to use on ARMv7 and ARMv8 |
| 21:14:12 | FromGitter | <yglukhov> plm: if not, that's a bug, i guess. |
| 21:14:26 | FromGitter | <yglukhov> plm: i'm using it on android and ios |
| 21:14:41 | federico3 | arm64 amd64 armel armhf x86 mips mispel powerpc ppc64 |
| 21:15:11 | FromGitter | <yglukhov> even avr |
| 21:15:32 | FromGitter | <yglukhov> basically, any architecture that has a c compiler for it =) |
| 21:16:26 | federico3 | no yglukhov: there's alpha, hppa, spark, s390 |
| 21:16:35 | plm | federico3: are you sure that workfs in ARMv7 and ARMv8 too? |
| 21:16:47 | niv | dom96: how's the blog coming? :p need any help with that? |
| 21:17:06 | FromGitter | <yglukhov> federico3: why would not nim work those? |
| 21:17:51 | plm | on https://github.com/nim-lang/Nim show just armv6l for the ARM arch |
| 21:18:01 | plm | federico3: ^ |
| 21:18:32 | federico3 | yglukhov I'm saying they are not supported |
| 21:18:42 | dom96 | niv: is the article done? |
| 21:19:19 | niv | i suppose. its not really an article, just a how to for absolute beginners. if you want it blog-style, i can probably rewrite it a bit |
| 21:19:35 | niv | i was actually asking if there's already a blog somewhere, because i can't find it - and if you'd need help with setting one up |
| 21:19:35 | dom96 | plm: best way to know is to try it |
| 21:20:03 | FromGitter | <yglukhov> federico3 : but that doesnt mean nim doesnt work there, right? |
| 21:20:04 | dom96 | niv: I was going to post it as a news post on nim-lang.org |
| 21:20:37 | niv | hmm okay, leave off on it for a day or two, maybe i'll polish it up a bit |
| 21:21:03 | federico3 | plm afaik works on an allwinner a10 - is it that a Cortex A8 ? |
| 21:21:31 | FromGitter | <yglukhov> i would say that nim would likely support anything that has a c compiler. if not, it should be easy fix. |
| 21:21:36 | niv | i have a nanopi neo hooked up here, its an allwinner h10 (i think). i can test stuff if you need me |
| 21:21:54 | federico3 | how about we put together a little wiki page with a list of archs/CPUs where Nim has been actually tested on? |
| 21:22:08 | plm | federico3: let me see |
| 21:22:09 | niv | dom96: another question since im already bothering you, if i may: how can i use nimble to specify project dependencies without having that project be a nimble package? |
| 21:22:37 | FromGitter | <yglukhov> federico3: good idea |
| 21:23:02 | dom96 | niv: You can't. |
| 21:23:04 | plm | federico3: The a10 is ARMv7 |
| 21:23:09 | niv | dom96: :( |
| 21:23:25 | plm | dom96: if works, why on github is wrong? |
| 21:23:46 | dom96 | plm: "In reality a lot more are supported, however they are not tested regularly." |
| 21:24:02 | niv | correction; my nanopi neo is an allwinner h3. a cortex a7. i've already run nim-stuff on it, worked fine |
| 21:24:32 | cheatfate | plm, as yglukhov said if gcc works on your platform and gcc version is more then 4.8.2, there is a big chance it works |
| 21:24:39 | * | stisa joined #nim |
| 21:24:48 | cheatfate | but we dont have access to test on this platforms |
| 21:24:56 | cheatfate | so we can't be sure |
| 21:25:16 | dom96 | niv: why can't you make that project a nimble package? |
| 21:25:29 | federico3 | I'm going to test on an Allwinner R8 Cortex A8 |
| 21:25:47 | niv | i guess i can? im not sure if thats the official approach? i dont want to publish it to the package repo. |
| 21:26:25 | dom96 | niv: You don't have to publish it |
| 21:26:29 | dom96 | It just needs a .nimble file |
| 21:26:32 | cheatfate | niv, you can not publish it but it still possible to install it via nimble |
| 21:26:37 | niv | okay! that answers it, thanks. |
| 21:27:02 | niv | clearly i have some reading to do on how nimble actually works |
| 21:27:05 | cheatfate | niv, this package is not in packages repository: https://github.com/cheatfate/asynctools |
| 21:27:14 | plm | cheatfate: "there is a big chance it works". Well, if nim use C code compiled, why is not 100% works where compile instead just "big chances"? |
| 21:27:46 | niv | alright, next question that's not answered in the README: is the <pkgname>.nim <pkgname>/.. pattern still canonical? because the README claims i should use bin/ src/ test/. |
| 21:28:46 | niv | is there a "ideal" package i can steal from on how to design my package repository? |
| 21:28:47 | cheatfate | plm, it depends on OS you are trying to use too... if it linux/bsd then everything must be fine, but if you will use some kind of realtime os or minix clone, then there can be troubles |
| 21:29:56 | plm | cheatfate: all right. Yes, I talking about just linux and bsd. |
| 21:30:07 | plm | cheatfate: do for that, where runs C runs nim? |
| 21:30:10 | dom96 | niv: Up to you. |
| 21:30:17 | federico3 | that's why I'm saying we should write it up in a wiki page |
| 21:30:24 | plm | cheatfate: so in ARMv8 (arm64) will works right? |
| 21:30:29 | dom96 | niv: The Nimble repo itself is a pretty good example I guess |
| 21:31:06 | niv | dom96: alright thank you. but the canonical pattern is that the user can just do "import <pkgname>" to get the whole thing, and maybe "import pkg/partsofit" to get specific things, right? |
| 21:31:23 | dom96 | niv: yep |
| 21:31:52 | niv | and things i dont want to expose via packages i should just hide somewhere, maybe in pkg/details/... |
| 21:31:55 | niv | alright, thanks |
| 21:32:55 | plm | cheatfate: ? |
| 21:32:58 | dom96 | niv: the convention for that is pkg/private/ |
| 21:33:14 | niv | good to know, thanks |
| 21:33:40 | federico3 | hm, the C.H.I.P. is an ARMv7 according to cpuinfo |
| 21:33:59 | yglukhov | plm: any arch should work. if its doesn't - we have to fix it. =) |
| 21:34:18 | plm | yglukhov: that is great |
| 21:34:24 | stisa | plm: it runs on my phone which should be armv8, does it count? |
| 21:34:58 | plm | yglukhov: I woule like to start to learn and to do many projects with something different of C. So montsh ago I see rust and start to learn it. |
| 21:35:13 | plm | So, what is advantage of nim over rust? |
| 21:35:24 | plm | stisa: all right |
| 21:35:59 | yglukhov | plm: lots. but what is important to _you_? |
| 21:37:21 | * | couven92 joined #nim |
| 21:37:27 | niv | wow, i forgot how slow this nanopi neo thing is. |
| 21:37:32 | niv | compiling nim takes forever |
| 21:38:17 | plm | yglukhov: I use for all my projects, since 2001 just python. But when I need more performance I to do just that part in C/C++ and to do a bind to python |
| 21:39:11 | plm | yglukhov: I would like to change the c parts to nim and still using python to bind to python if need. Or just nim if is needed. |
| 21:39:38 | yglukhov | plm: well thats a simple one. Nim is pretty natural for pythonists to move to. |
| 21:42:07 | plm | yglukhov: I not understand how nim works in "background". The cnim compiler generate code to C and after runs c compiler? |
| 21:42:38 | yglukhov | defining externc procs is as easy as in C. there's one quirk, however. calling such procs from foreign environments/threads previously unseen by nim, will likely crash, because you have to init nim's gc and (when using TLS emulation) tls. |
| 21:44:17 | yglukhov | plm: "nim c" command will build the executable by producing C code and calling C compiler. "nim cpp" - same, but cpp compiler. "nim js" - nim just spits out a single js file (no other tools needed). |
| 21:45:59 | yglukhov | also there's nimscript... =) |
| 21:46:31 | plm | yglukhov: well, but if nim c generate C ode and after compile. If C has problems (I mean - is not good enouch) with threads, or it is not asyncrounous (like go and nim) I thinking: will be just c code com c compiler. whats will be the advantage over write that just directaly in C:? |
| 21:46:37 | yglukhov | plm: if you havent done through tutorial and manual, i would suggest doing that, bts |
| 21:46:42 | yglukhov | *btw |
| 21:47:12 | plm | s com/with |
| 21:47:30 | yglukhov | plm: you can say the same about assembler. but tell you what. everything compiles down to it ;) |
| 21:47:49 | yglukhov | so C for Nim is like asm for C |
| 21:48:25 | yglukhov | Nim gives you memory safety, methods, metaprogramming, generics, etc |
| 21:48:32 | plm | yglukhov: well, so everthing I to do with nim I can to do with C, the same code. |
| 21:48:55 | * | bjz quit (Quit: Textual IRC Client: www.textualapp.com) |
| 21:49:00 | smt | the benefit is you can write in lovely clean nim code and have it spit out fast C code |
| 21:49:15 | smt | well, just one benefit |
| 21:49:48 | yglukhov | exactly. except in you spend 20 hours for writing and debugging 200LOC, in nim you do the same job with 20LOC in 1 hour. smth like that. |
| 21:49:50 | plm | every other languace generate C code and after compile with C compiler? |
| 21:50:10 | yglukhov | ... except in C you ... |
| 21:50:52 | * | bjz joined #nim |
| 21:51:13 | niv | Error: unhandled exception: Cannot allocate memory [OSError] .. oops |
| 21:51:30 | yglukhov | plm: btw, why are you using python. you can do everything in C, you know... |
| 21:51:34 | yglukhov | =) |
| 21:51:49 | niv | i suppose the test suite isnt happy with 512MB of ram |
| 21:51:53 | plm | yglukhov: python is faster to development |
| 21:52:05 | plm | yglukhov: but somthings it is slow |
| 21:52:07 | yglukhov | plm: same holds for Nim |
| 21:52:11 | * | libman quit (Ping timeout: 240 seconds) |
| 21:52:15 | yglukhov | but Nim is fast as C |
| 21:52:33 | plm | yglukhov: python generate c code and after compile using c compiler? |
| 21:52:50 | plm | yglukhov: sorry, it is bytecode |
| 21:52:54 | yglukhov | plm: no, it uses its own vm. |
| 21:53:05 | plm | yglukhov: but go for example, does the same like as nim? |
| 21:53:22 | federico3 | nope |
| 21:53:41 | plm | go not generate a c code and use after a c compiler? |
| 21:53:49 | plm | how it does? |
| 21:53:52 | federico3 | no, most language do not |
| 21:54:02 | plm | how the most languages does? |
| 21:54:09 | federico3 | it generates a binary directly |
| 21:54:24 | plm | and why the nim not generate the binary directaly too? |
| 21:54:36 | yglukhov | plm: well "directly" is a really blurry term here |
| 21:55:11 | * | nsf quit (Quit: WeeChat 1.7) |
| 21:55:17 | plm | yglukhov: ok, but why nim not generate the binary "directly" too? |
| 21:57:13 | niv | clang/gcc is incredibly good at optimising code, stuff a self-rolled binary compiler would have to reimplement, most likely worse |
| 21:57:23 | yglukhov | plm: there are no benefits in generating the binary directly. |
| 21:57:35 | yglukhov | at least i can't see any benefits. |
| 21:57:55 | niv | well, not requiring a extra compiler suite :) |
| 21:57:56 | yglukhov | while going through C gives tons of benefits. |
| 21:58:29 | plm | yglukhov: well, I see a very large beneft generate a C code and after compile it: |
| 21:58:33 | * | atl```` joined #nim |
| 21:58:39 | plm | yglukhov: where runs C, runs nim |
| 21:59:06 | yglukhov | 1. nim has powerful low-level controls in the language for what C code to generate. |
| 21:59:40 | yglukhov | 2. You can actually see the generated code |
| 22:00:24 | yglukhov | 3. There are platforms (embedded) for which only C vendor compilers exists, so you're kinda locked on C there. Or on Nim! :D |
| 22:00:51 | plm | yglukhov: But, sorry for my ignorance. C has problems (is not so good) with thread safe or something that I not remember, like as asyncronous network, etc. Anyway, if you are generate code to C, nim will be the same benefits and "problems" like as C, not? Well, comparing with other language that will generate directaly to binary, they has the advantage to solve the C "problems". Am I right? |
| 22:00:52 | yglukhov | 4. The codegen part of the compiler is easier to dive into for willing contributors. |
| 22:01:23 | atl```` | plm: no |
| 22:01:36 | yglukhov | plm: C doesn't have such problems. C is low-level. |
| 22:01:46 | atl```` | plm: all those issues are caused by the people writing the code |
| 22:01:50 | plm | People, If I am wrong, please clarify to me! |
| 22:01:55 | atl```` | not by the language itself |
| 22:01:56 | yglukhov | low-level is historically the opposite of safe |
| 22:02:39 | yglukhov | using C requires you to really know what you're doing, and be very accurate. |
| 22:03:02 | yglukhov | newer languages tend to disallow unsafe things. |
| 22:03:30 | yglukhov | but you still want them when we're talking low-level. |
| 22:05:39 | plm | yglukhov: so C is perfect to everything tecnology, hardware, applications and so on? Example, I have a new hardware with 120 cores, I would like to do an app to use all thjat cores. Or I would like to do a asyncrounous webservice, like as go has native or python3.5 (asyncio), C is possible to do that perfectly? In other works, are not limits in C to the power and flexibilty? |
| 22:09:00 | atl```` | you could do it in C, it's just that python and go have abstractions to make it easier to manage |
| 22:09:06 | atl```` | that is the difference between low level and high level |
| 22:09:29 | atl```` | high level has a lot of abstraction, and sometimes there's so much abstraction you lose access and features to things like manual memory management |
| 22:09:35 | atl```` | in turn, you get a higher velocity of development |
| 22:09:40 | yglukhov | performance and efficiency in terms of hardware - C (philosophers can argue thoug). engineering productivity (writing more features in less time) - not C. |
| 22:11:13 | yglukhov | Nim is high level and safe by default. but it doesn't keep you from going low-level should you need it. |
| 22:11:52 | plm | yglukhov: So nim is the perfect language |
| 22:12:08 | plm | yglukhov: it is fast to developement and the power of C |
| 22:12:21 | federico3 | I wish it was that simple |
| 22:12:22 | yglukhov | so by default you get productivity like python or better (type safety is a huge productivity gain IMO), and performance of native language. |
| 22:13:05 | plm | yglukhov: But I am curious: If nim generate C code and after call c (gcc for example) compiler to compile taht code, why do you need a GC (garbage collector) on nim? |
| 22:14:26 | plm | federico3: "I wish it was that simple" but yglukhov say ^ that is jsut simple, is a reality. |
| 22:15:34 | yglukhov | plm, federico3: in reality philosophers argue :D |
| 22:15:39 | federico3 | plm: meanwhile, Nim is working on the C.H.I.P. |
| 22:16:35 | federico3 | plm: there are many more variables than speed of development and execution |
| 22:18:52 | yglukhov | federico3: to name a few? |
| 22:21:57 | federico3 | memory use, features [and there can be many], maturity, familiarity, popularity, ease of learning, ... |
| 22:23:11 | * | atl```` quit (Quit: Lost terminal) |
| 22:25:06 | yglukhov | memory use - thats performance/efficiency. everything else - those are of what productivity consists at the end of the day. |
| 22:25:13 | yglukhov | imo =) |
| 22:25:30 | yglukhov | but thats philosophy anaway |
| 22:26:19 | yglukhov | * im doing lots of typos so id better go sleep. see you around. |
| 22:36:52 | plm | sorry for the long time |
| 22:37:12 | plm | yglukhov: federico3 could you answer my question about GB? |
| 22:37:33 | plm | I not understand still if you answer it |
| 22:37:38 | cheatfate | GB? |
| 22:37:47 | federico3 | uh? GB? |
| 22:37:51 | plm | sorry |
| 22:37:54 | plm | GC |
| 22:38:01 | plm | "20:13 < plm> yglukhov: But I am curious: If nim generate C code and after call c (gcc for example) compiler to compile taht |
| 22:38:03 | plm | code, why do you need a GC (garbage collector) on nim?" |
| 22:38:31 | federico3 | Nim has its own optional GC |
| 22:38:59 | plm | federico3: but why is optino if at the end is a C code calling a C compiler? |
| 22:40:04 | cheatfate | plm, you can code in Nim and avoid GC (i dont like GC too, so i will not protect Nim's GC) |
| 22:40:23 | cheatfate | but its possible to make nim programs which not uses GC |
| 22:41:15 | cheatfate | you just need to avoid usage of complex types like `string`, `sequence`, `tuple` and you can work without GC by allocating and freeing memory by yourself using alloc/dealloc functions |
| 22:41:44 | kulelu88 | can Nim determine the return type from a proc by itself or is it required to specify it? |
| 22:42:03 | cheatfate | kulelu88, try to use `:auto` |
| 22:42:11 | kulelu88 | ty |
| 22:43:58 | kulelu88 | also, how does 1 use the modulo operator ? I cannot find the docs for it |
| 22:44:44 | plm | are there any advantge of rust over nim? |
| 22:45:26 | kulelu88 | plm: that's quite a question to ask |
| 22:45:36 | euantor | At the minute: more libraries available, big company providing financial backing |
| 22:46:08 | euantor | But the downsides (in my eyes) is the syntax (e.g.: the use of lifetime specifiers everywhere) |
| 22:46:14 | smt | if you're newer/less experienced with programming like i am, rust is very complex to learn imo |
| 22:47:27 | kulelu88 | Rust is like learning C in some ways. It is a lot 'safer' than C (or so they say), but difficult to read/understand for beginners, as smt mentions |
| 22:47:31 | plm | smt: I liked nim becouse I already use python |
| 22:47:54 | smt | yeah i came from both python and go and found nim to be pretty easy to learn (without going into the more advanced stuff it can do anyway) |
| 22:47:58 | plm | I knew the Nim today by this title: "Nim — A Programming Language That Combines Best Of Python, Go, And Rust" |
| 22:48:26 | plm | As I like Python and I was interested in rust and go, I start to read the article |
| 22:48:32 | plm | https://fossbytes.com/nim-programming-language-nimrod/ |
| 22:49:23 | plm | smt: your idea is just to stop to use python and go and to use just Nim? |
| 22:49:41 | kulelu88 | that's a bad idea |
| 22:49:49 | plm | kulelu88: why? |
| 22:49:53 | kulelu88 | especially for web stuff. Nim doesn't have a mature eco-system |
| 22:49:53 | smt | yeah i wouldnt outright say that |
| 22:50:27 | kulelu88 | Nim could do what the some people do with Rust. Yank out the slower Python stuff and make it faster with a Nim interface |
| 22:50:52 | Vladar | What's funny, I found Nimrod page while googling for a python-like language with strong typing |
| 22:51:37 | plm | Anyway, what is advantage of rust over Nim? |
| 22:51:45 | plm | sorry |
| 22:51:51 | plm | yo told me above |
| 22:52:18 | kulelu88 | plm: I think only the core guys could answer that, but its late for quite a few of them so perhaps try asking some time tomorrow (or in roughly 12 hours) |
| 22:52:38 | plm | kulelu88: all right |
| 22:52:55 | plm | who is the big company behind of rust? |
| 22:53:02 | kulelu88 | Mozilla |
| 22:53:04 | Xe | mozilla |
| 22:53:13 | plm | hmm |
| 22:53:20 | plm | and behind Nim |
| 22:53:21 | plm | ? |
| 22:53:30 | euantor | Nobody |
| 22:53:32 | kulelu88 | Andreas and Dominique :P |
| 22:53:40 | euantor | And the community |
| 22:53:58 | federico3 | ...and my axe! |
| 22:54:05 | plm | ahahah |
| 22:54:24 | plm | just two persons? |
| 22:54:48 | kulelu88 | Nim actually has the potential for longevity, as it is more open and driven by a community instead of 1 authoritative company |
| 22:55:27 | federico3 | plm: there are 250 contributors on github |
| 22:56:18 | plm | I will to check the rust how many contributors :) |
| 22:56:50 | plm | federico3: 1670 |
| 22:57:29 | kulelu88 | Go and Rust have way more people involved |
| 23:00:05 | plm | rust works just on x86 and x86_64 |
| 23:00:22 | plm | why is so difficult for them to support other archs? |
| 23:00:30 | plm | like as Nim does. |
| 23:00:53 | kulelu88 | Nim compiles to C, which can run on most platforms |
| 23:01:10 | plm | kulelu88: and the rust, how it works? |
| 23:01:24 | kulelu88 | I believe Rust uses LLVM to compile |
| 23:01:27 | euantor | Compiles to LLVM IR |
| 23:02:14 | plm | But LLM runs is mostly archs |
| 23:07:08 | plm | euantor: ^ |
| 23:08:03 | euantor | I think it would be possible for them to support other archs, but their sodlib isn't written with other archs in mind |
| 23:08:07 | euantor | *stdlib |
| 23:08:24 | euantor | But I'm not an expert, so could be completely wrong |
| 23:09:42 | euantor | https://forge.rust-lang.org/platform-support.html |
| 23:09:56 | euantor | They do support ARM, but it's a "Tier 2" platform |
| 23:18:34 | plm | euantor: but they do not support ARMv8 |
| 23:19:03 | plm | I mean that so rust, direfferently of Nim, it compile directaly to binary. |
| 23:19:21 | euantor | Yeah, it doesn't seem like they support ARMv8 |
| 23:19:25 | plm | euantor: So they can't to say: "where runs C, runs rust" |
| 23:19:34 | plm | Am I correct? |
| 23:20:04 | euantor | I'm not sure I've seen them say that. They're pretty much dependant on what LLVM can support |
| 23:20:45 | euantor | As I said, I'm no expert in either Rust or Nim |
| 23:23:14 | plm | euantor: But the Nim can use the LLVM too http://nim-lang.org/question.html (At the end of page) |
| 23:23:39 | federico3 | *can* |
| 23:23:58 | euantor | Yes, and Nim also has other backends, such as compiling to javaScript |
| 23:24:16 | euantor | I believe somebody at one point was working on a backend that emitted LLVM IR too |
| 23:25:33 | plm | what is the advantage to compilling to javascript? |
| 23:25:43 | plm | To do a webpage/site? |
| 23:26:07 | euantor | Yep |
| 23:28:21 | plm | euantor: but is not possible change javascript and see the results on browser how is easy with chrome/firefox using firebug for example. |
| 23:28:59 | euantor | I've not used the JS backend, so I can't answer that I'm afraid |
| 23:32:20 | * | yglukhov quit (Remote host closed the connection) |
| 23:35:25 | * | stisa quit () |
| 23:36:39 | Vladar | The idea of compiling to js is to make the js code is to reduce the chance of mistake (same thing with compiling to C, actually) |
| 23:39:16 | * | Kingsquee joined #nim |
| 23:39:59 | * | chemist69 quit (Ping timeout: 264 seconds) |
| 23:42:36 | * | Vladar quit (Ping timeout: 255 seconds) |
| 23:44:18 | * | chemist69 joined #nim |
| 23:44:34 | * | Vladar joined #nim |
| 23:54:37 | federico3 | plm: Nim just worked on the C.H.I.P. with the Allwinner R8 |
| 23:54:55 | federico3 | also crosscompiling from amd64 worked |