00:01:47 | Araq | what's wrong with some people? |
00:01:57 | krux02 | dom96: thanks |
00:03:20 | krux02 | he didn't apologize and started another crap, I think the ban is very well justified. |
00:04:11 | krux02 | Araq: did you see the integration test of "removed compiler internal list implementation #5371" just passed? |
00:04:26 | krux02 | https://github.com/nim-lang/Nim/pull/5371 |
00:05:30 | * | ofd quit (Quit: Textual IRC Client: www.textualapp.com) |
00:08:42 | krux02 | dom96: let's hope he doesn't find out how to use irc, wher you do not need an account to spam |
00:11:35 | Araq | krux02: why do we need this change? |
00:11:49 | Araq | how can it be green when you haven't updated Nimble? |
00:12:17 | krux02 | does it test nimble? |
00:13:04 | krux02 | I wrote a compatibility layer in lists.nim, so that TLinkedList functions do work on seq, too |
00:13:51 | krux02 | that function is in lists.nim and instantly depricated, but it allows that code that is written to work with lists to still run |
00:15:47 | krux02 | and we need this update, because it gives me satisfaction in eleminating legacy |
00:16:00 | krux02 | I like eleminating legacy |
00:16:14 | krux02 | that is also a way for me to get comfortable with the code base |
00:17:25 | * | carterza joined #nim |
00:17:25 | dom96 | 'night |
00:18:33 | krux02 | and there was a todo in compiler/lists.nim that started with "Remove this" |
00:18:35 | krux02 | so I did |
00:18:38 | * | def-pri-pub joined #nim |
00:20:01 | carterza | Varriount : not necessarily UE4 ships with physx integration |
00:21:23 | krux02 | carterza: a nim wrapper for bullet physics should be possible with the c++ backend of the compiler |
00:21:31 | * | Kingsquee joined #nim |
00:21:53 | krux02 | it would be a lot of emit statements, and it would force to use the c++ compilation target, but it is possible as far as I know |
00:22:26 | carterza | I guess I need to look at urhonimo because I think Araq did it there |
00:22:49 | carterza | thanks krux02 |
00:23:29 | * | Kingsquee quit (Client Quit) |
00:23:32 | * | Kingsqueee joined #nim |
00:23:40 | krux02 | would be nice if you keep me updated when you start a project like that. I might be able to help, I have written a lot of wrappers already |
00:23:57 | carterza | Sure thing |
00:24:19 | carterza | and thanks for the offer |
00:24:22 | krux02 | if you have a github repo for that, I will follow it |
00:25:18 | carterza | okay cool - as soon as I figure out where to start and get something going I’ll link it |
00:47:56 | * | aziz quit (Remote host closed the connection) |
00:51:01 | * | vlad1777d quit (Remote host closed the connection) |
00:54:52 | carterza | krux02: I guess the linear math stuff is the place to start - https://github.com/bulletphysics/bullet3/blob/master/src/LinearMath/btScalar.h - seems to be at the root of a lot of the other LinearMath classes |
00:55:32 | carterza | I’m setting up a repo now, not really sure how to proceed but I’ll get that going at least |
00:59:11 | carterza | https://github.com/zacharycarter/casing |
01:08:53 | FromGitter | <Varriount> shashlick: You can override and use a static version of pcre, but there's currently no |
01:11:19 | carterza | be back in a bit |
01:15:21 | FromGitter | <Varriount> Araq, dom96: With regards to zzz125, his github profile suggests he's a Go supporter, which his past comments support. |
01:20:27 | * | djellemah quit (Ping timeout: 240 seconds) |
01:22:16 | * | djellemah joined #nim |
01:26:06 | FromGitter | <Varriount> carterza: What about chipmunk? |
01:33:56 | FromGitter | <zacharycarter> Only will work for 2d |
01:34:48 | FromGitter | <Varriount> krux02: Will emits be necessary? I thought the Nim C++ import machanism was fairly well-developed. |
01:36:03 | FromGitter | <Varriount> @zacharycarter This looks interesting too: https://github.com/RandyGaul/qu3e |
01:45:25 | FromGitter | <zacharycarter> It does, i saw that last night |
01:47:48 | krux02 | Varriount: If you want to import templates, I think you cannot get around emit statements. |
01:48:11 | krux02 | at least I heaily doubt it. |
01:49:55 | rauss | When trying to use a shared library with dynlib, do I still edit the .h files to something that works well with nim? I guess, if I'm using an .so, is that all that's needed? |
01:52:32 | * | yglukhov joined #nim |
01:54:41 | FromGitter | <Varriount> rauss: The shared library itself can be compiled normally. |
01:54:58 | FromGitter | <Varriount> The only time you edit the .h files is when feeding them into C2Nim to generate wrappers. |
01:56:41 | rauss | Varriount: Say I have three .h files. I specify in each one a ref to the .so file with dynlib. Right? |
01:56:51 | * | yglukhov quit (Ping timeout: 252 seconds) |
01:57:10 | FromGitter | <Varriount> rauss: What? I don't follow. |
01:57:14 | rauss | The reason I'm confused is the c2nim docs say #header and #dynlib are mutually exclusive, which implies I might not need to use the header files at all |
01:57:36 | FromGitter | <Varriount> Yes. You specify the name of the dynamic library to be loaded. |
01:58:03 | FromGitter | <Varriount> C2Nim then decorates each wrapped function with the dynlib pragma. |
01:59:01 | rauss | Okay thanks. I had everything compiling fine with #header directives, but the nim compilation actually hangs indefinitely so I'm trying to switch to the recommended #dynlib instead. |
02:03:07 | * | def-pri-pub quit (Quit: leaving) |
02:03:17 | rauss | s/compiling/generating |
02:18:35 | libman | Good news on Nim's popularity ranking progressing in the TIOBE index - https://forum.nim-lang.org/t/671/9#17423 :D |
02:24:11 | * | gokr quit (Ping timeout: 240 seconds) |
02:33:27 | * | djellemah quit (Ping timeout: 240 seconds) |
02:34:50 | * | djellemah joined #nim |
02:40:11 | * | chemist69 quit (Disconnected by services) |
02:40:16 | * | chemist69_ joined #nim |
02:42:35 | shashlick | Varriount: thanks |
02:44:10 | FromGitter | <Varriount> shashlick: You can override it, as long as you abide by pcre's license. There's no native Nim regular expression engine. |
02:45:09 | shashlick | Varriount: makes sense since it's much easier to just wrap one |
02:45:28 | FromGitter | <Varriount> Although, a more interesting idea would be to use compile time procedures to incorporate pcre.dll into the executable as an array/string/sequence, and write it to a file on install. |
02:45:48 | shashlick | anyway, I have an easy way to carry the DLL within my EXE and write it to TEMP on first run |
02:46:11 | shashlick | ya, that's what I did for my experiments with libcurl.dll |
02:46:22 | shashlick | staticRead is a great feature of Nim |
02:50:34 | FromGitter | <Varriount> Shashlick: Hm, maybe Nim's installer could do that. |
02:51:09 | shashlick | who maintains the Windows installer? I'd be happy to help |
02:51:25 | FromGitter | <Varriount> Then again, such an approach typically opens security holes if the libraries depended on are world-writeable. |
02:51:51 | FromGitter | <Varriount> shashlick: Look at finish.nim in the main repository |
02:53:05 | FromGitter | <Varriount> Shashlick: for securities sake, if the installer uses that method, lock the file using the Windows api and do a checksum on it |
02:53:24 | FromGitter | <Varriount> Before loading the library |
02:54:09 | FromGitter | <Varriount> Otherwise an attacker can replace the library when it's extracted |
02:55:55 | shashlick | TEMP on Windows is in the user's profile dir, won't it be locked to that user? |
02:56:08 | shashlick | although, when you talk of Nim, it is installed as admin |
02:57:17 | FromGitter | <Varriount> shashlick: What happens if malware is running, and replaces a library that is in TEMP with a poisoned version? |
02:57:54 | FromGitter | <Varriount> Doing so between the point the installer writes the library out and loads it |
02:57:54 | shashlick | assuming it is running as current user, it could as well write any DLL or EXE in the user's profile dir |
02:58:27 | FromGitter | <Varriount> Hm, true. |
02:59:19 | FromGitter | <Varriount> The best solution, if the installer is elevated, is for it to write the libraries out to a secure system path that non-elevated programs can't write to |
03:00:54 | shashlick | well, since it is an installer, it can write out nim.exe and xyz.dll into the same directory (like it is today) |
03:01:09 | shashlick | there's no incentive to bundle it into nim.exe and extract it at first run |
03:01:38 | shashlick | unless i'm understanding you wrong |
03:02:55 | FromGitter | <Varriount> Shashlick: Hm, maybe I'm just overconcerned, since the installer doesn't usually need to be elevated anyway. |
03:03:52 | shashlick | varriount: I think that's an issue though - the installer today doesn't request to elevate and install fails altogether since it cannot write to Program Files |
03:04:16 | FromGitter | <Varriount> Normally you don't want any elevated program (like an installer or configuration tool) to depend on a dll that can be written to by a regular program. |
03:04:45 | FromGitter | <Varriount> Because then a regular program can poison the depended-upon dll |
03:05:23 | shashlick | it still creates a desktop shortcut and path entries, and an entry in the registry for uninstall but doesn't put down any files |
03:05:31 | shashlick | so you cannot uninstall it |
03:05:35 | carterza | back |
03:06:03 | FromGitter | <Varriount> shashlick: Probably a bug/oversight |
03:10:11 | * | rosshadden quit (Read error: Connection reset by peer) |
03:10:11 | * | rauss quit (Read error: Connection reset by peer) |
03:19:35 | * | rosshadden joined #nim |
03:22:30 | * | rauss joined #nim |
03:54:21 | * | yglukhov joined #nim |
03:54:39 | carterza | haven’t been able to find much help regarding my problem with ode, just going to ignore phyiscs for now and continue with 3d rendering stuff |
03:59:12 | * | yglukhov quit (Ping timeout: 276 seconds) |
04:09:09 | krux02 | carterza, what is your problem? |
04:09:39 | carterza | my rigid bodies go crazy upon contact |
04:09:48 | shashlick | does Windows have a built-in regex lib that Nim could wrap? |
04:09:49 | carterza | even though I have friction set to infinity |
04:09:58 | carterza | and restitution set to zero |
04:10:28 | carterza | also it randomly crashes, I’m sure it’s something I’m doing wrong but stil discouraging |
04:10:50 | shashlick | I see System.Text.RegularExpressions, but that's .NET, not sure if Nim can wrap those DLLs |
04:10:55 | krux02 | well rigid bodies is not easy |
04:11:14 | krux02 | especially when it becomes messy with a lot of rigid bodies in contact |
04:11:39 | krux02 | default engines can only do collision respose pairwise |
04:11:42 | krux02 | and then they iterate |
04:11:52 | krux02 | and do lot's of hacks to handle corner cases |
04:12:43 | carterza | yeah |
04:12:56 | carterza | this is a pretty simple example though |
04:13:02 | carterza | just a single rigid body colliding with a plane |
04:13:11 | krux02 | you have to break it down somehow |
04:13:25 | krux02 | first you have to make sure that your detection works rock solid |
04:13:48 | krux02 | just make a simple demo where you can drag objects on each other and see if everything is detected correctly |
04:13:51 | carterza | yeah that seems to be working fine |
04:14:11 | krux02 | then you check if your collision response parameters are all correct |
04:14:19 | * | devted quit (Quit: Sleeping.) |
04:14:22 | rauss | shashlick: Out of curiosity what are you trying to do? It sounds like you're trying to wrap a regex lib but nim appears to have one |
04:14:35 | krux02 | that means when two object intersect, how much do they intersect, and it which direction do you want to push them apart? |
04:14:43 | krux02 | do it interactively again |
04:14:51 | krux02 | check if everything works the way you want |
04:15:04 | krux02 | and that start to apply collision response |
04:15:31 | carterza | makes sense |
04:16:23 | krux02 | when you start to add too many things at the same time that you are not very familiar with, it becomes hard to detect where something went wrong when something goes wrong |
04:16:28 | krux02 | so break it down |
04:16:33 | carterza | yeah exactly |
04:16:36 | krux02 | and make each problem simple |
04:17:54 | shashlick | rauss: one less lib to carry? |
04:18:17 | rauss | shashlick: Hah okay |
04:22:02 | krux02 | maybe verbal expressions: https://github.com/VerbalExpressions?page=1 |
04:32:38 | * | krux02 quit (Remote host closed the connection) |
04:33:04 | carterza | http://imgur.com/a/td3Qp |
04:33:05 | carterza | point light |
04:36:51 | shashlick | krux02: very interesting |
04:37:22 | shashlick | but it uses a real regex lib underneath |
05:01:00 | * | nsf joined #nim |
05:08:31 | * | rusua quit (Quit: Connection closed for inactivity) |
05:20:35 | carterza | spot lights http://imgur.com/a/EZde2 |
05:20:43 | carterza | or a spot light anyway |
05:24:38 | FromGitter | <Varriount> carterza: Going for the creepy look? |
05:25:35 | carterza | :D |
05:26:10 | carterza | I wish I could strive for a certain look, I’m not artistic enough for that :P |
05:26:37 | carterza | I think I’m going to need to build an editor |
05:26:40 | carterza | soon |
05:37:40 | FromGitter | <Varriount> carterza: What are you aiming for, 2d or 3d? |
05:38:03 | carterza | well - I don’t really have art assets to make a 2d game at the moment |
05:38:10 | carterza | not the scope of game I want to make anyway |
05:38:27 | carterza | I think coming up with placeholder 3d assets is going to be easier than placeholder 2d art |
05:38:39 | * | ibk joined #nim |
05:38:39 | carterza | maybe not... |
05:38:42 | FromGitter | <Varriount> Well, there are sites out there that provide free-use tile maps |
05:38:53 | carterza | this is true |
05:39:07 | carterza | I’m making a procedurally generated roguelike game |
05:39:19 | carterza | about exploring derelict spaceships and hostlie alien planets |
05:39:31 | carterza | I’ve prototyped a lot of the procedural generation stuff in Java |
05:39:33 | carterza | with Libgdx |
05:39:53 | carterza | I’m not set on 2d or 3d yet either way, although I think if I end up going 3d I’ll probably just use UE4 |
05:39:54 | FromGitter | <Varriount> An editor for things like level layout and such - is that what you're aiming for? |
05:40:16 | carterza | well my level layout is really going to be determined at runtime |
05:40:22 | carterza | I guess I don’t necessarily need a level editor |
05:40:37 | carterza | I was just thinking it would be useful if others ever use this “thing” I’m building |
05:40:51 | FromGitter | <Varriount> Because if it's just for textures, I don't see why GIMP/Photoshop won't do. |
05:41:11 | carterza | ah yeah I agree |
05:41:18 | carterza | I meant more for like laying out scenes and saving them to disk |
05:41:37 | FromGitter | <Varriount> Ah. |
05:42:08 | carterza | it’s a good point though I didn’t really think about - since most of my game is going to be procedural I might just not use an editor |
05:42:18 | carterza | I’m going to try to do skeletal animation now |
05:42:27 | carterza | which if I can get right, means I’m going to keep going with 3d |
05:42:34 | carterza | if I struggle I’ll probably just say eff it and focus on 2d |
05:42:55 | FromGitter | <Varriount> Carterza: For what it's worth, if the engine is flexible enough, you could be writing the next libgdx |
05:43:32 | FromGitter | <Varriount> Game development is an area I believe Nim is well suited for. |
05:43:37 | carterza | I agree totally |
05:43:56 | carterza | about nim being great for gd |
05:44:14 | carterza | if my library turns into a nim libgdx I’ll be estatic, but lots of work to be done first haha |
05:45:16 | ftsf | yeah nim is lovely for game dev |
05:54:56 | * | Snircle quit (Quit: Textual IRC Client: www.textualapp.com) |
05:55:54 | * | yglukhov joined #nim |
06:00:23 | * | yglukhov quit (Ping timeout: 264 seconds) |
06:00:50 | * | libman quit (Quit: Connection closed for inactivity) |
06:06:45 | shashlick | nim is lovely period |
06:07:21 | shashlick | enjoyed Python for several years, made me lazy, but the GIL and performance limitations are just unbearable |
06:08:13 | shashlick | Nim makes that feel like torture and that's a very big deal since Python has been a luxury all these years |
06:12:55 | FromGitter | <Varriount> To be fair, Nim doesn't just let you do multithreading right off the bat |
06:13:41 | FromGitter | <Varriount> You usually have to use channels or some of the asyncpool stuff to do anything meaningful |
06:27:44 | * | rauss quit (Quit: WeeChat 1.7) |
06:39:45 | shashlick | question: is it possible to create a global variable whose name is the contents of another variable? |
06:58:58 | * | ftsf quit (Remote host closed the connection) |
07:00:03 | * | rokups joined #nim |
07:22:02 | * | bjz joined #nim |
07:27:02 | * | couven92 joined #nim |
07:32:38 | FromGitter | <vegansk> @shashlick, use macros for that |
07:46:34 | rokups | is there a low lvl container suitable for use in gc code? Araq? |
07:47:18 | shashlick | vegansk: I've been looking at macros, but don't see how I can write a global const = staticRead as part of the macro. Looks like some more easy reading of the macro documentation |
07:47:47 | * | Andris_zbx joined #nim |
07:49:45 | FromGitter | <vegansk> @shashlick: ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=58a16518f045df0a223e1d86] |
07:50:17 | * | filcuc joined #nim |
07:50:33 | FromGitter | <vegansk> Just replace var with const |
07:50:41 | FromGitter | <vegansk> if you need const |
07:51:08 | * | bjz quit (Read error: Connection reset by peer) |
07:51:51 | * | bjz joined #nim |
07:52:30 | shashlick | wow thanks! what's static[string]? |
07:52:40 | * | yglukhov joined #nim |
07:55:00 | FromGitter | <vegansk> If you need to pass some value to macro, you should use ``static[value_type]`` or you will get NimNode instead of concrete value |
08:09:45 | * | Ven joined #nim |
08:11:31 | Araq | rokups: CellSeq? |
08:11:35 | * | chemist69_ quit (Quit: WeeChat 1.7) |
08:12:49 | * | Vladar joined #nim |
08:13:15 | * | gokr joined #nim |
08:28:58 | FromGitter | <vegansk> @Araq, if ``gch.stackBottom.isNil`` is not acceptable, what should I use to find out if GC initialized or not? |
08:29:52 | Araq | the question is: why do you have to? |
08:30:18 | Araq | there is a thread local bool to check against multiple inits |
08:30:34 | Araq | and threads created by Nim must not call setupForeignThreadGC |
08:31:32 | FromGitter | <vegansk> @Araq, answered here: https://github.com/nim-lang/Nim/pull/5369#discussion_r100742313 |
08:36:22 | * | djellemah_ joined #nim |
08:36:37 | * | djellemah_ quit (Remote host closed the connection) |
08:38:35 | Araq | vegansk: alternatively Nim's createThread can set the thread local bool to 'true' |
08:38:41 | Araq | that would be the clean solution. |
08:39:01 | * | yglukhov quit (Remote host closed the connection) |
08:40:35 | FromGitter | <vegansk> @Araq, what if localGcInitialized will have 3 possible values: not initialized, initialized in the Nim thread, initialized in the foreign thread? |
08:41:27 | FromGitter | <vegansk> so it will be safe to call tearDownForeignThreadGc in the Nim thread |
08:42:10 | Araq | ah yeah, that's good |
08:42:30 | FromGitter | <vegansk> Ok, fixing it |
08:43:01 | Araq | please also look into https://github.com/nim-lang/Nim/issues/5382 |
08:43:35 | * | byte512 joined #nim |
08:44:36 | * | carterza quit (Quit: carterza) |
08:44:58 | FromGitter | <vegansk> I have no expirience with pcre, but I'll try |
08:46:04 | Araq | well you know the git diff |
08:46:48 | FromGitter | <vegansk> I don't want just revert these changes :-) |
08:48:36 | rokups | but CellSeq cant be used for anything other than cells |
08:50:54 | * | bjz quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
08:51:35 | Araq | rokups: yes. what do you need to do? |
08:52:03 | * | bjz joined #nim |
08:52:20 | rokups | get rid of that custom linked list code for storing stacks and using something not written by me so its cleaner and safer |
08:53:34 | rokups | tbh i tried including lists.nim (after commenting out asserts) but something didnt quite click. gch.stacks.append() complained about gch.stacks being "Type" and not "var Type", not sure why that was |
08:54:04 | rokups | oh i remembered, lists also used refs, which i noticed later, so they wont work in gc i think |
08:57:51 | * | yglukhov joined #nim |
08:58:54 | * | Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
09:02:00 | * | Ven joined #nim |
09:02:06 | Araq | we have thread safe linked lists iirc |
09:02:15 | Araq | but these are threadsafe and so slower |
09:02:37 | Araq | your custom linked list is fine except it sucks for the write barrier |
09:03:13 | rokups | i noticed quite some containers are duplicated all over the place |
09:03:47 | rokups | be nice if all that could be moved around to reuse more code, maybe with some template magic |
09:05:05 | * | chemist69 joined #nim |
09:07:56 | * | couven92 quit (Quit: Client disconnecting) |
09:12:00 | rokups | btw that bootstrapping with nimCoroutines was false success. something weird was going on and compiler reported success few times but its still broken. :\ |
09:13:50 | * | Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
09:18:17 | shashlick | vegansk, Varriount: based on our discussions, here's a gist to save and load binary dependencies within the EXE itself - https://gist.github.com/genotrance/10fb380f54dc3024c1292d1595aa38a6 |
09:18:59 | shashlick | just need to define a sequence of file names to include and call the macro at the beginning |
09:19:03 | shashlick | thanks for the help! |
09:23:41 | * | yglukhov quit (Remote host closed the connection) |
09:24:18 | * | yglukhov joined #nim |
09:29:51 | * | bjz quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
09:35:39 | * | bjz joined #nim |
09:37:39 | Araq | rokups: they are not duplicated, they are subtly different and extracting the common logic into templates is not without its own problems. |
09:38:07 | Araq | just look at tables.nim, it's now so full of templates that's a "edit and hope" business |
09:38:23 | Araq | well the test suite tells you when you got it wrong, but still. |
09:42:37 | * | Ven joined #nim |
09:44:13 | FromGitter | <vegansk> @shashlick, you are welcome :-) |
09:47:39 | FromGitter | <vegansk> @Araq, there is a problem. I need to set ``localGcInitialized`` declared in ``gc_common.nim`` from ``threads.nim``. But ``threads.nim`` is included before ``mmdisp.nim``. What do you think if I move ``localGcInitialized`` variable in ``threads.nim``? |
09:49:44 | Araq | yeah |
09:53:40 | FromGitter | <vegansk> ok |
09:54:11 | * | sz0 joined #nim |
09:56:08 | * | carterza joined #nim |
09:57:09 | Araq | that thing should also be renamed to 'threadOwner' or something |
09:58:43 | Araq | of type ThreadOwner = enum ForeignUinit, ForeignInit, SelfInit |
10:02:13 | FromGitter | <vegansk> I have that enum :-) ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=58a184231465c46a565a3721] |
10:04:55 | * | xet7 joined #nim |
10:12:39 | FromGitter | <Araq> good enough |
10:15:24 | * | Arrrr joined #nim |
10:15:24 | * | Arrrr quit (Changing host) |
10:15:24 | * | Arrrr joined #nim |
10:19:35 | * | PMunch joined #nim |
10:21:22 | FromGitter | <vegansk> But then I thought that it's not the owner, or initialization state. It's the thread's type :-) @Araq, can you look at #5369 again?\ |
10:27:42 | * | bjz quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
10:30:00 | Araq | seems fine, will merge when tests are green |
10:30:10 | * | bjz joined #nim |
10:31:04 | * | yglukhov quit (Remote host closed the connection) |
10:32:00 | * | yglukhov joined #nim |
10:32:59 | FromGitter | <vegansk> @dom96, can you look at this thread please: https://forum.nim-lang.org/t/2790. There is the problem with HttpClient performance on Linux at least. |
10:33:42 | * | yglukhov quit (Remote host closed the connection) |
10:36:22 | * | bjz_ joined #nim |
10:38:38 | * | bjz quit (Ping timeout: 255 seconds) |
10:40:07 | * | PMunch quit (Ping timeout: 256 seconds) |
10:40:15 | * | Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
10:44:08 | * | tankfeeder joined #nim |
10:44:57 | FromGitter | <Varriount> shashlick: The `static ` typeclass marks values known at compile time |
10:48:23 | * | gokr quit (Ping timeout: 264 seconds) |
10:50:47 | * | yglukhov joined #nim |
10:54:20 | * | PMunch joined #nim |
10:56:52 | * | carterza quit (Quit: carterza) |
11:20:38 | * | yglukhov quit (Remote host closed the connection) |
11:23:27 | * | bjz_ quit (Ping timeout: 240 seconds) |
11:26:35 | * | bjz_ joined #nim |
11:31:41 | * | yglukhov joined #nim |
11:43:29 | * | Kingsqueee quit (Quit: https://i.imgur.com/qicT3GK.gif) |
11:54:38 | * | bjz joined #nim |
11:56:29 | * | bjz_ quit (Ping timeout: 255 seconds) |
11:57:20 | * | adeohluwa joined #nim |
12:01:24 | * | adeohluwa quit (Remote host closed the connection) |
12:01:39 | * | arnetheduck joined #nim |
12:02:19 | * | Snircle joined #nim |
12:07:41 | * | gokr joined #nim |
12:24:15 | * | sz0 quit (Quit: Connection closed for inactivity) |
12:27:22 | * | carterza joined #nim |
12:28:10 | * | yglukhov quit (Remote host closed the connection) |
12:31:29 | * | carterza quit (Ping timeout: 240 seconds) |
12:32:20 | * | bjz quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
12:40:33 | * | carterza joined #nim |
12:40:39 | * | bjz joined #nim |
12:42:57 | * | yglukhov joined #nim |
12:49:43 | * | vlad1777d joined #nim |
12:49:55 | * | PMunch quit (Quit: leaving) |
12:59:46 | * | PMunch joined #nim |
13:00:01 | * | couven92 joined #nim |
13:01:07 | * | couven92 quit (Client Quit) |
13:03:16 | * | PMunch quit (Client Quit) |
13:07:35 | * | bjz quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
13:10:26 | * | StarBrilliant quit (Ping timeout: 255 seconds) |
13:22:41 | * | devted joined #nim |
13:29:01 | * | carterza quit (Quit: carterza) |
13:30:40 | * | rektide_ joined #nim |
13:30:47 | * | Seannachie_ joined #nim |
13:32:10 | * | nmooney quit (Write error: Broken pipe) |
13:32:10 | * | rektide quit (Write error: Broken pipe) |
13:39:13 | * | couven92 joined #nim |
13:48:55 | * | gokr quit (Ping timeout: 240 seconds) |
13:50:08 | * | yay quit (Quit: yay) |
14:09:30 | * | zevlg joined #nim |
14:09:50 | * | fredrik92 joined #nim |
14:13:46 | demi- | is there a library or existing piece of functionality in the stdlib that does what python's shlex does? (parse and separate a string based on how it would be interpreted on a shell) |
14:16:42 | flyx | „on a shell“ um, which kind of shell? bash? csh? fish? |
14:17:18 | dom96 | demi-: There is nothing for that in the stdlib AFAIK |
14:17:36 | flyx | I don't think there is, but it probably would not be hard to write a lexer grammar for it |
14:17:46 | demi- | https://docs.python.org/2/library/shlex.html#module-shlex |
14:18:51 | demi- | at the bottom it describes the parsing rules flyx |
14:19:49 | demi- | dom96: thank you for the threadvar advice yesterday, that is how i ultimately ended up implementing it -- feels a bit crude but i am still learning |
14:19:56 | * | freddy92 joined #nim |
14:20:19 | flyx | this module does not seem to be well-defined |
14:20:19 | dom96 | demi-: no problem, but my advice remains: you don't need threads. |
14:20:34 | flyx | „When operating in non-POSIX mode, shlex *will try to obey* to the following rules.“ |
14:20:40 | dom96 | Unless I am missing something you are planning to do in the future. |
14:21:15 | flyx | I generally favor writing an own lexer instead of relying on a module that tells me it will try to obey some rules |
14:21:54 | flyx | but, no, to my knowledge, there is no such functionality (to answer the original question) |
14:22:06 | Araq | https://nim-lang.org/docs/os.html#parseCmdLine,string |
14:22:09 | * | fredrik92 quit (Ping timeout: 240 seconds) |
14:22:28 | demi- | dom96: it is possible i am misunderstanding some of the core principles of how nim operates in regards to threads, which i can only hope to understand by trying to use them. |
14:22:51 | * | fredrik92 joined #nim |
14:22:52 | * | freddy92 quit (Read error: Connection reset by peer) |
14:23:04 | Araq | I use the "search" feature here to find it: https://nim-lang.org/docs/lib.html |
14:23:16 | Araq | maybe that should be also on the frontpage or something |
14:23:36 | Araq | it usually finds what I'm looking for... |
14:24:02 | Araq | whoever wrote that did a fine job, oh wait it was me. |
14:24:02 | FromGitter | <Varriount> demi-: Nim is much more strict with regards to shared memory. |
14:24:34 | FromGitter | <Varriount> Araq: The search function has been a great help to me in the past. :D |
14:24:34 | * | PMunch joined #nim |
14:25:05 | * | carterza joined #nim |
14:25:19 | * | fredrik92 quit (Client Quit) |
14:25:25 | FromGitter | <Varriount> demi-: Each thread in Nim has it's own heap (or in less accurate terms, garbage collector) |
14:25:26 | * | devted quit (Quit: Sleeping.) |
14:25:38 | demi- | Araq: hmmm, i do use that fairly frequently, perhaps it needs a bit more work on how it performs searches? like if i type "parsecmd" it shows up but not if i type "command line" |
14:26:09 | demi- | even though that string is part of the documentation of that method |
14:26:52 | Araq | well that's a fair point |
14:27:26 | Araq | but I didn't want a google site search |
14:27:38 | demi- | perhaps a weighted index of the contents of the method documentation would help? |
14:27:53 | Araq | oh it does weight stuff |
14:28:05 | Araq | it's just that it uses theindex.html for all its knowledge |
14:28:12 | * | elrood joined #nim |
14:28:15 | demi- | aah i see |
14:28:16 | Araq | and theindex lacks documentation comments |
14:29:01 | Araq | I think the docs should use more often `foo`:idx: |
14:30:22 | demi- | Varriount, right, so if i mark something as referenced globally and hold that reference, shouldn't i be able to use it across threads as one would in C? |
14:30:44 | FromGitter | <Varriount> demi-: But which stack would the reference belong to? |
14:30:56 | FromGitter | <Varriount> And how would other stacks handle things like refcounting? |
14:31:26 | demi- | presumably the main thread? and other stacks would have to not manage refs to it -- would have to be done manually |
14:31:57 | FromGitter | <Varriount> demi-: Yes, but since it's a reference type, the garbage collector will always try to manage it. |
14:32:37 | demi- | i guess this is why i am asking -- shouldn't there be a way to tell it to not? |
14:32:37 | FromGitter | <Varriount> You can pass around pointers to objects if you want to share memory, but not references. |
14:32:49 | FromGitter | <Varriount> demi-: Only by using pointers. |
14:33:00 | FromGitter | <Varriount> Pointers can cross thread boundaries. References cannot. |
14:33:27 | demi- | ah i see, so if I make a pointer to this object, i can then deref the point and operate on it? |
14:33:46 | FromGitter | <Varriount> Yes, if the procedures operate on an object, rather than a pointer. |
14:34:05 | demi- | ok, i think that was the answer i was looking for then |
14:34:35 | demi- | thank you! |
14:34:51 | FromGitter | <Varriount> demi-: One moment. |
14:35:53 | FromGitter | <Varriount> demi-: The downside is this - say we have a `type Foo = ref object`. All procedures for Foo are going to hinge on the fact that `Foo` is a reference type. |
14:37:30 | FromGitter | <Varriount> Thus, even if you do (in some other part of your code) `type FooObj = object of Foo`, then use a pointer to pass a `FooObj` across thread boundaries, you won't be able to manipulate it. |
14:37:59 | demi- | hmmm |
14:38:10 | demi- | this seems extremely inelegant. |
14:38:54 | * | yglukhov quit (Remote host closed the connection) |
14:39:40 | FromGitter | <Varriount> demi-: But safe. What if one of `Foo`'s procedures stuffs puts the object in a sequence or something? |
14:40:10 | * | rauss joined #nim |
14:40:41 | demi- | is the general practice to not share things across threads, and it so there are other mechanisms for delivery of updates? |
14:40:50 | FromGitter | <Varriount> demi-: Channels |
14:41:29 | FromGitter | <Varriount> Unless @Araq has a better/faster implementation. |
14:42:17 | demi- | hmmm, is there a decent example of these in use so i can see what a basic implementation is like? |
14:42:39 | FromGitter | <Varriount> demi-: https://nim-lang.org/docs/channels.html |
14:42:47 | demi- | yeah i'm reading that right now |
14:43:09 | FromGitter | <Varriount> Although, I admit that the module description " The current implementation of message passing is slow and does not work with cyclic data structures." doesn't inspire confidence. |
14:43:13 | demi- | i was asking for a concrete example of the usage of this API |
14:45:00 | demi- | so to use what i was attempting to implement yesterday, i have an asynchttpclient that fires the progress updated callback; i have another thread that i want to respond to the change in progress of downloading a file, how would i fit channels into that? |
14:45:50 | dom96 | demi-: if your goal is to learn about threading in Nim then feel free to use them, just remember that they are not necessary for your use case. |
14:46:25 | * | Arrrr1 joined #nim |
14:46:25 | * | Arrrr quit (Disconnected by services) |
14:46:33 | * | Arrrr1 quit (Client Quit) |
14:46:54 | FromGitter | <Varriount> demi-: https://github.com/search?l=Nim&q=channels&type=Code&utf8=%E2%9C%93 |
14:48:13 | demi- | dom96: indeed |
14:49:22 | FromGitter | <Varriount> Although, I do wonder - even with the whole "separate heap" architecture, what other mechanisms could be used to simplify threading. |
14:49:36 | FromGitter | <Varriount> Language-level or otherwise. |
14:50:16 | dom96 | I believe we will get a shared heap eventually (Araq, correct me if I'm wrong) |
14:50:41 | dom96 | well, a shared heap that is simpler to use |
14:50:46 | dom96 | we already have allocShared |
14:52:26 | Araq | shared heap or not, unprotected accesses to globals are evil and will continue to be considered bad code |
14:53:06 | Araq | most of the time when I am in the situation the compiler prevents me from making mistakes |
14:54:41 | FromGitter | <Varriount> demi-: Unfortunately, I have to agree with Araq |
14:55:25 | FromGitter | <Varriount> Even with locks, accessing global data tends to lead to thread contention over the lock. |
14:56:05 | Araq | varriount: to annoy you a bit: globals in Rust are unsafe ;-) |
14:56:42 | demi- | ok i think i understand this, but how are the channels being initialized here https://github.com/nim-lang/Nim/blob/5f685bb0e6b2d68b9796e6a7d29469ce3f3b38ec/tests/parallel/tarray_of_channels.nim |
14:57:28 | demi- | and i assume they are under a special rule because if one where to do this to any other type of variable it would raise a GC unsafe error? |
14:57:29 | FromGitter | <Varriount> Araq: Bah, you know I'm allergic to that name. |
14:59:42 | Araq | varriount: the thread contention is not really an argument, channels too use locks internally and even if they are lockfree the contention stays |
15:01:14 | dom96 | demi-: they're intialised using open() |
15:01:23 | FromGitter | <Varriount> demi-: If you plan on using channels, keep the message sizes small (like, integers or small structures) |
15:01:36 | Araq | demi-: indeed they use an undocumented feature to tell the compiler "shut up, it's safe" :P |
15:01:45 | * | yglukhov joined #nim |
15:01:53 | dom96 | ooh, undocumented features, gimme. |
15:01:55 | demi- | haha |
15:02:06 | Araq | well I dunno if that's still required though |
15:02:18 | Araq | in principle they don't need it. |
15:05:29 | * | yglukhov quit (Remote host closed the connection) |
15:06:02 | * | yglukhov joined #nim |
15:06:45 | demi- | ok, so if i understand the docs pages correctly, you should use channel.tryRecv() inside of a thread's event loop to process new incoming messages, and if that fails then defer until the next cycle of the loop? |
15:07:35 | * | devted joined #nim |
15:10:06 | * | mjanssen quit (Remote host closed the connection) |
15:10:12 | * | PMunch quit (Quit: leaving) |
15:10:26 | * | yglukhov quit (Ping timeout: 255 seconds) |
15:11:05 | * | yglukhov joined #nim |
15:11:38 | * | gokr joined #nim |
15:17:25 | dom96 | demi-: it depends |
15:17:36 | dom96 | recv() will block your thread which is probably what you want |
15:18:09 | demi- | dom96: is that the general principle though, assuming i don't want it to block |
15:18:15 | * | elrood_ joined #nim |
15:18:23 | * | elrood quit (Read error: Connection reset by peer) |
15:19:20 | dom96 | yes |
15:20:53 | demi- | ok, cool this seems pretty clean and straight-forward then |
15:25:06 | * | carterza quit (Ping timeout: 240 seconds) |
15:31:28 | shashlick | general question - how do you determine if something is of value in the stdlib versus a 3rd party module? |
15:32:00 | FromGitter | <Varriount> shashlick: Why? |
15:32:23 | * | vlad1777d quit (Quit: Leaving) |
15:34:13 | shashlick | the gist I shared earlier today, is it something that would be useful in stdlib, worth sharing as a module, or it is fairly obvious and no need to share? |
15:36:07 | shashlick | https://gist.github.com/genotrance/10fb380f54dc3024c1292d1595aa38a6 |
15:36:07 | * | ibk quit (Quit: Connection closed for inactivity) |
15:37:27 | FromGitter | <Varriount> Sashlick: Oh, I thought you meant "how can I tell if a type is from stdlib though code" |
15:38:59 | FromGitter | <Varriount> shashlick: The normal procedure is to create a pull request and wait for comments |
15:39:38 | shashlick | okay cool |
15:40:10 | dom96 | well, I would say the normal procedure is to ask here |
15:40:36 | dom96 | I don't want people wasting time creating a PR if I then have to simply reject it. |
15:42:12 | dom96 | But to be honest, nowadays I tend to err on the side of "create a Nimble package out of it first, and if it turns out to be very useful and stable then we will adopt it into the stdlib" |
15:42:48 | shashlick | i'm not sure how common it is to carry dependencies within the EXE but would make it easier for Nim users to ship single file executables |
15:43:04 | FromGitter | <Varriount> shashlick: it might be better to just include in finish.nim |
15:43:11 | dom96 | In the lead up to Nim 1.0 I would prefer to keep Nim's standard library slim. |
15:43:15 | shashlick | dom96: that sounds like a reasonable approach |
15:43:35 | dom96 | shashlick: Happy to hear it :) |
15:43:52 | FromGitter | <andreaferretti> @shashlick how would that be used? |
15:43:56 | federico3 | dom96: why? |
15:44:28 | dom96 | federico3: because it's easier to add things later than remove things once they've been in the stdlib for a long time. |
15:44:28 | FromGitter | <andreaferretti> I mean, once you have the dependencies included literally in your compiled program |
15:44:44 | FromGitter | <andreaferretti> how can you use them? |
15:45:03 | FromGitter | <andreaferretti> for instance, I see you include executable files as well as DLLs |
15:45:21 | FromGitter | <andreaferretti> how can then you use them? |
15:45:21 | federico3 | dom96: maybe a way to get the best of both worlds would be to tag procs in the stdlib as core and non-core |
15:45:40 | FromGitter | <andreaferretti> say, how do you execute your embedded curl? |
15:46:03 | FromGitter | <andreaferretti> or import a function defined in your embedded DLL |
15:46:16 | dom96 | andreaferretti: I think the .dll is written to disk beside the .exe before the .exe is executed |
15:46:31 | dom96 | well, before the .exe's execution tries to load the dll |
15:46:48 | FromGitter | <andreaferretti> ah ok |
15:47:01 | FromGitter | <andreaferretti> so, in fact, the program copies part of its data segment to disk |
15:47:20 | FromGitter | <andreaferretti> and then makes the os load them as executable |
15:47:26 | shashlick | the con of this approach is that exe is larger so perhaps takes longer to load |
15:47:35 | FromGitter | <andreaferretti> I see |
15:48:04 | cheatfate | andreaferretti: its also possible to load it without using disk |
15:48:11 | FromGitter | <andreaferretti> what is more strange, though, is that the single file program then expands to a multiple files one |
15:48:26 | FromGitter | <andreaferretti> @cheatfate that would be interesting |
15:48:31 | FromGitter | <andreaferretti> how do you do that? |
15:49:11 | cheatfate | andreaferretti i can describe you how to make it on windows |
15:49:18 | dom96 | That is pretty cool. |
15:49:36 | dom96 | I'm surprised there is enough time to write it to disk before Nim tries to load the DLL. |
15:49:53 | dom96 | bbl |
15:49:54 | cheatfate | its like you implement os loader, and its possible |
15:50:07 | FromGitter | <andreaferretti> I would be interested |
15:50:20 | FromGitter | <andreaferretti> even though I use linux almost exclusively |
15:50:35 | FromGitter | <Varriount> @andreaferretti Ding: https://webcache.googleusercontent.com/search?q=cache:wwqQ5VJ9kBMJ:https://www.joachim-bauch.de/tutorials/loading-a-dll-from-memory/+&cd=1&hl=en&ct=clnk&gl=us&client=ms-android-att-us |
15:51:00 | Araq | shashlick: what's wrong with putting the DLL next to the .exe? |
15:51:07 | Araq | that's how Windows works. |
15:51:30 | Araq | it's all the other OSes that fuck around with shared libs and then wonder they get no adoption... |
15:51:44 | shashlick | Araq: that's where I put it as part of extraction |
15:52:01 | FromGitter | <andreaferretti> @Varriount thank you |
15:52:52 | * | pregressive joined #nim |
15:52:53 | shashlick | dom96: if you load the DLL after this step, it works just fine. E.g. import libcurl after extraction |
15:53:12 | FromGitter | <Varriount> Araq: Consider security implications if the executable is run as administrator |
15:54:14 | shashlick | cheatfate: how do you load DLL without extracting? especially if you don't open it yourself (e.g. libcurl module does the actual impoof) |
15:54:46 | FromGitter | <Varriount> shashlick: Read that link I showed @andreaferretti |
15:54:49 | shashlick | cheatfate: that will be useful since it will avoi Varriount's security concern |
15:55:04 | * | yglukhov quit (Remote host closed the connection) |
15:55:47 | shashlick | around DLLs, not EXEs though, unless you can execute an EXE also from memory |
15:58:30 | * | pregress_ joined #nim |
15:58:30 | * | pregressive quit (Read error: Connection reset by peer) |
16:00:42 | * | yglukhov joined #nim |
16:05:54 | * | yglukhov quit (Read error: Connection reset by peer) |
16:06:12 | * | yglukhov joined #nim |
16:08:06 | * | gokr quit (Ping timeout: 240 seconds) |
16:10:44 | * | yglukhov quit (Ping timeout: 255 seconds) |
16:12:30 | cheatfate | shashlick, EXEs can be loaded in same way, but with some limitations |
16:16:10 | cheatfate | what the problem to create new thread and start execution from entry point? |
16:16:41 | cheatfate | the only problem is to handle command line so you need to modify your own executable PEB to satisfy arguments to executable |
16:17:30 | cheatfate | and of course you need to replace ExitProcess() so you can catch exit from your application |
16:18:54 | * | tankfeeder left #nim ("Leaving") |
16:18:56 | shashlick | https://github.com/fancycode/MemoryModule/ does all the work for DLLs |
16:19:40 | * | Arrrr joined #nim |
16:19:40 | * | Arrrr quit (Changing host) |
16:19:40 | * | Arrrr joined #nim |
16:22:50 | cheatfate | shashlick, what is the difference between dll and exe? |
16:23:30 | shashlick | looks like there's a sample to run an EXE too |
16:24:02 | cheatfate | shashlick, as i said before you need to get address of entry point of your mapped embedded exe |
16:24:10 | cheatfate | and then simply CreateThread(entry point) |
16:25:39 | cheatfate | but when your embedded application call ExitProcess() both processes will exit so you need to replace ExitProcess() |
16:25:55 | cheatfate | to catch it by your downloader/loader |
16:27:25 | cheatfate | to make it fully functional not only exitprocess must be intercepted |
16:27:41 | cheatfate | and also command line must be prepared for console applications |
16:45:46 | * | gokr joined #nim |
16:46:33 | * | carterza joined #nim |
16:48:01 | * | gokr quit (Read error: No route to host) |
16:49:12 | carterza | I’m trying to figure out what to pass as the third argument to - https://www.khronos.org/registry/OpenGL-Refpages/es3/html/glDrawElementsBaseVertex.xhtml - can anyone help me? |
16:49:42 | carterza | it’s supposed to accept a pointer to the location where the indices in the buffer are stored |
16:49:56 | carterza | most examples I see in C / C++ simply pass a integral value to this argument |
16:50:08 | carterza | but that doesn’t work in Nim as it wants a pointer, not sure how to satisfy this |
16:50:20 | shashlick | cheatfate: interesting - i'll look into it |
16:52:58 | * | Andris_zbx quit (Remote host closed the connection) |
16:55:38 | Arrrr | carterza: use unsafeAddr(seq[0]) |
16:55:46 | carterza | thank you |
16:56:32 | Arrrr | https://nim-lang.org/docs/manual.html#statements-and-expressions-the-addr-operator |
16:56:41 | carterza | errr - I don’t have a sequence |
16:56:57 | Arrrr | https://nim-lang.org/docs/system.html#addr,T |
16:57:09 | Arrrr | It works with arrays to |
16:57:10 | Arrrr | *too |
16:57:13 | carterza | okay thanks |
16:57:19 | FromGitter | <Varriount> Carterza: wait |
16:57:34 | FromGitter | <Varriount> I believe that's the storage location for the stay in the shader |
16:57:45 | FromGitter | <Varriount> Not an address in your program |
16:58:04 | FromGitter | <Varriount> *array on the shader |
16:58:06 | carterza | I think you’re correct Varriount |
16:58:18 | carterza | in the example I’m looking at he’s doing - (void*)(sizeof(unsigned int) * m_Entries[i].BaseIndex). |
16:58:30 | carterza | which would produce an int casted to a void pointer |
16:58:44 | carterza | cast* |
17:00:05 | * | elrood_ quit (Quit: Leaving) |
17:02:05 | * | pregress_ quit (Remote host closed the connection) |
17:02:12 | FromGitter | <Varriount> https://www.khronos.org/opengl/wiki/GLAPI/glDrawElementsBaseVertex |
17:02:19 | * | pregressive joined #nim |
17:02:38 | * | Trustable joined #nim |
17:02:50 | * | pregressive quit (Remote host closed the connection) |
17:03:08 | carterza | yeah how do I do the cast to the pointer type for the byte offset Varriount? |
17:03:08 | * | pregressive joined #nim |
17:03:13 | carterza | that’s what I’m stuck on |
17:03:38 | * | pregressive quit (Remote host closed the connection) |
17:03:56 | * | pregressive joined #nim |
17:04:26 | * | pregressive quit (Remote host closed the connection) |
17:04:43 | * | pregressive joined #nim |
17:05:14 | * | pregressive quit (Remote host closed the connection) |
17:05:30 | * | pregressive joined #nim |
17:05:49 | carterza | I tried - cast[ptr void](sizeof(uint) * int skinnedModel.entries[i].baseIndex)[] |
17:05:52 | carterza | bu that doesn’t work |
17:06:02 | * | pregressive quit (Remote host closed the connection) |
17:10:19 | carterza | figured it out I think - cast[pointer](sizeof(uint) * int skinnedModel.entries[i].baseIndex) |
17:10:24 | carterza | duh |
17:17:16 | FromGitter | <Varriount> Hrm, the irc bridge needs to escape special characters |
17:17:55 | * | filcuc quit (Ping timeout: 256 seconds) |
17:23:22 | dom96 | carterza: Arrrr: btw you should use 'addr' if possible. |
17:30:15 | * | nubunto joined #nim |
17:33:21 | * | vlad1777d joined #nim |
17:54:02 | * | yglukhov joined #nim |
17:59:00 | * | yglukhov quit (Ping timeout: 276 seconds) |
18:06:29 | * | nubunto quit (Ping timeout: 240 seconds) |
18:24:27 | * | krux02 joined #nim |
18:29:56 | krux02 | Araq: still any complaints to for my pull request? |
18:30:16 | krux02 | I mean the one for TLinkedList |
18:31:27 | Araq | sorry, but this doesn't improve anything as far as I'm concerned and only creates work for us. the path list supports "add to front" and "add to back" and your seq replacement doesn't really capture this idea |
18:32:51 | Araq | but we can let dom96 decide. :-) |
18:35:54 | dom96 | You might need to be a bit patient for that. Really not feeling that great today. |
18:38:20 | dom96 | Araq: Does this need the "add to front"/"add to back" functionality? |
18:38:23 | * | tankfeeder joined #nim |
18:38:39 | * | tankfeeder left #nim (#nim) |
18:38:40 | dom96 | btw guys, we have a job opening: https://forum.nim-lang.org/t/2795 |
18:38:44 | * | brson joined #nim |
18:40:24 | Araq | dom96: sure, if you add to front, this path gets priority over the others |
18:40:31 | Araq | if you add to back, it's considered last |
18:40:35 | * | couven92 quit (Quit: Client disconnecting) |
18:41:13 | dom96 | isn't there a linked list implementation in the stdlib? |
18:41:28 | dom96 | I'm guessing TLinkedList is defined somewhere in the compiler |
18:43:37 | Araq | yeah but maybe it's not a list, but a deque |
18:50:12 | subsetpark | Can someone give me some guidance about setupForeignThreadGc? I think some of the crashes I'm seeing are due to calling Nim from Python using a threaded test framework. |
18:52:17 | Araq | subsetpark: well you need to call setupForeignThreadGc in every callback you pass to Python's API |
18:52:58 | subsetpark | That means that I need to compile with --threads:on and --tlsEmulation:off, even if I don't do any threaded operations within the Nim itself? |
18:56:01 | Araq | no, Python runs everything in the GIL, so with --threads:off global storage instead of thread local storage is used and things should work out fine |
18:56:34 | * | Trustable quit (Remote host closed the connection) |
18:56:41 | Araq | but if the GIL is not involved for some reasons, then things are dangerously unsafe |
18:58:53 | subsetpark | Yeah, so I guess it must not be an issue with Thread GC |
19:00:19 | subsetpark | I think these crashes might not be related to Nim at all - if some other part of the Python code is encountering a segfault, and the process dies, is it possible that Nim would emit "Illegal storage access. (Attempt to read from nil?)" even if the segfault didn't originate in the Nim code? |
19:00:24 | * | devted quit (Ping timeout: 252 seconds) |
19:00:45 | Araq | memory corruptions are non-local. |
19:01:04 | Araq | Nim could corrupt some Python extension or the core Python VM. or vice versa. |
19:01:29 | subsetpark | Oh sure, I get that - I am more wondering: |
19:01:55 | FromGitter | <Varriount> When using python and threads in a C extension, you have to be careful to check that you hold the gil before manipulating Python objects. |
19:02:02 | subsetpark | Let's say that some Python extension corrupts the core Python VM, and Nim is not involved at all. Would Nim still output that message when it dies? |
19:02:43 | * | yglukhov joined #nim |
19:03:17 | Araq | subsetpark: yes, you should compile with -d:noSignalHandler |
19:03:55 | Araq | Python has its own signal handlers, better use these instead |
19:06:11 | subsetpark | Ok, that makes sense... I still see the SIGSEGV message though. What does that tell me? |
19:06:24 | * | cjbest joined #nim |
19:06:55 | Araq | well what's the full output? |
19:06:56 | subsetpark | oh, wait, forget that |
19:07:54 | subsetpark | ah ok, now the python test just hangs |
19:08:18 | subsetpark | and after ~10 secs regorts a Segmentation fault |
19:09:40 | * | libman joined #nim |
19:12:22 | subsetpark | Ok, awesome. So I think that means the segfault is Python's fault, not Nim's :) |
19:14:30 | Araq | subsetpark: run your code under valgrind |
19:15:19 | krux02 | Araq: well seq can very well add to the front, it is called `myseq.insert(value, 0)` |
19:16:59 | Araq | krux02: that's slow and uncommon. when one reads it, it screams "bug or requires documentation" |
19:17:33 | krux02 | moves every element one step further, so it has linear complexity, but on a sequences with lengths in the order of 10, just just doesn't matter at all and the fact that the much more familiar api from seq can be used just outweights this thing |
19:17:33 | * | couven92 joined #nim |
19:17:56 | krux02 | how is that slow? |
19:18:03 | krux02 | linked lists are slow |
19:18:42 | FromGitter | <Varriount> krux02: Not for pushes and pops from beginning/end |
19:19:31 | FromGitter | <Varriount> Admittedly, that is one of their only benefits |
19:19:37 | Araq | well I'm sure we all the performance differences |
19:19:42 | Araq | *all know |
19:20:28 | Araq | insert(value, 0) is O(n) vs linked list prepend O(1), seqs have better cache locality yadayadayada |
19:20:46 | krux02 | well inserting to the front of a seq (linear memory) is orders of magnitude faster that just iterating a linked list, because with a linked list each element has a potential cache miss |
19:21:14 | dom96 | This isn't used in any "hot paths", right? |
19:21:28 | krux02 | so even when you constantly insert in the middle or somewhere else, inserting in linear memory is almost always faster than inserting in a list |
19:21:32 | dom96 | or at least, the prepend operation isn't |
19:21:49 | krux02 | it is just used to add a path the the search path |
19:21:58 | krux02 | and to collect compiler arguments |
19:22:15 | krux02 | the performance is just completely irrelevant. |
19:22:19 | dom96 | federico3: is your Nim benchmarking site still operating? |
19:22:28 | Araq | this is not about performance, though add lots of paths and the O(N^2) will kill you |
19:22:36 | Araq | but it is about API design anyway. |
19:22:40 | krux02 | and even if it would be relevant I still think seq would be faster |
19:24:09 | krux02 | and for api design using a seq is oviously a win, because a seq every nim developer already knows how to use |
19:24:34 | krux02 | So I think in both API design and in performance a seq is just a win |
19:24:40 | federico3 | dom96: no (an issue on the SBC), but I can set up a new SBC if someone cares about its output |
19:24:42 | krux02 | it is also better typed |
19:25:07 | krux02 | because the seq has an element type, TLinkedList required to use inheritance of the base list elemnt type |
19:25:08 | Araq | krux02: a deque conveys the intention much better, IMO |
19:25:14 | * | yglukhov quit (Remote host closed the connection) |
19:26:00 | krux02 | the argument not to use a deque, is because a seq is just simpler. |
19:26:21 | krux02 | and a seq also is ordered like a deque |
19:27:46 | dom96 | I dislike this `options.searchPaths.keepItIf( cmpPaths(it, path) != 0 )` |
19:28:01 | krux02 | can you give a link? |
19:28:19 | Araq | it's actually an ordered set... |
19:28:19 | dom96 | is `excludePath` used anywhere else? |
19:28:27 | dom96 | https://github.com/nim-lang/Nim/pull/5371/files#diff-3cfdfab46b76fca4a44ba7cdd5447096R339 |
19:28:28 | FromGitter | <barcharcraz> Filcuc: ping |
19:29:34 | dom96 | also I wonder what that `-g` flag adds (i added a comment on GitHub) |
19:29:57 | krux02 | -g adds debug information |
19:30:09 | * | yglukhov joined #nim |
19:30:39 | krux02 | sorry that was not inteded to be in the commit |
19:30:56 | krux02 | it should have been in another pull request that has nothing to do with this one. |
19:31:08 | krux02 | I'll remove it, so we don't need to discuss it anymore |
19:31:54 | euantor | This kind of thing is really great to see: https://www.reddit.com/r/nim/comments/5trzpj/a_nim_success_story/ |
19:34:35 | dom96 | euantor: awesome, thanks for posting the link :) |
19:36:11 | Araq | - bringToFront(lazyPaths, it) |
19:36:11 | Araq | + # bring to front |
19:36:11 | Araq | + for j in countDown(i,1): |
19:36:13 | Araq | + swap(lazyPaths[j], lazyPaths[j-1]) |
19:36:15 | Araq | |
19:36:35 | Araq | I think the list representation was ok :P |
19:36:58 | Araq | it's just that it should have used generics instead of inheritance and provide some convenient iterator |
19:37:22 | krux02 | I think it shouldn't exist |
19:37:33 | krux02 | I mean the methods, maybe |
19:37:38 | krux02 | but then work an seq |
19:38:17 | krux02 | proc bringToFront[T](arg: var seq[T]; pos: int) = ... |
19:39:42 | krux02 | but that bringToFront could then be in either sequtils ore algorithm |
19:40:45 | dom96 | I didn't look through it all but I do think it's a good idea to replace this custom TLinkedList |
19:41:12 | dom96 | Araq: And are you saying that a Queue should be used instead of a seq? |
19:42:10 | Araq | I don't mind removing TLinkedList but the replacement should be better |
19:42:10 | * | yglukhov quit (Remote host closed the connection) |
19:42:34 | dom96 | okay, so what in your opinion should be the replacement? |
19:43:04 | krux02 | I personally are against queue. My principle is "keep it simple stupid" and that means for me to use seq, unless there is a good reason to use something else. |
19:43:10 | Araq | a custom data structure for path handling |
19:43:18 | dom96 | On a different topic, Rust is moving to travis/app veyor: https://twitter.com/rustlang/status/831219313189089280 |
19:43:32 | Araq | dom96: oh come on, who cares. |
19:43:41 | Araq | that's #nim-offtopic |
19:43:45 | dom96 | No it's not |
19:43:49 | Arrrr | What is app-veyor? |
19:44:04 | dom96 | It reinforces our choice of CI |
19:44:12 | FromGitter | <Varriount> @Araq @krux02: What exactly is being discussed? |
19:44:13 | krux02 | type PathList = seq[string] |
19:44:31 | krux02 | https://github.com/nim-lang/Nim/pull/5371 |
19:44:32 | dom96 | Varriount: #5371 |
19:44:46 | Araq | it's add least a distinct seq[] so that 'add' can guard against duplicates |
19:45:14 | Araq | dom96: fine... |
19:45:18 | dom96 | Araq: and it's perfectly in line with what was being discussed here a while back |
19:46:38 | krux02 | a distinct seq forces explicit casting when operations from algorithm or sequtils want to be applied |
19:48:32 | krux02 | Araq: on the other heand it would be completely sufficient to just call removeDuplicates on the seq before it is used as a path list |
19:48:45 | krux02 | and even if it has duplicates, I doubt that it would make a difference |
19:50:50 | Araq | sorry, have to go, consider this fight won. |
19:52:09 | * | rokups quit (Quit: Connection closed for inactivity) |
19:52:51 | krux02 | yay :-) |
19:53:58 | FromGitter | <Varriount> I'd just make a inherited and/or distinct sequence type (or a type that uses a sequence for containing data). |
19:54:48 | krux02 | Varriount: My argument is that you should have a very good reason to introduce a new type, when you don't have that, just use a seq |
19:55:01 | krux02 | the KISS principle |
19:55:28 | krux02 | keep it simple stupid |
19:56:20 | krux02 | and that is what I did, I replaced a weired list implementation with a seq |
19:56:33 | FromGitter | <Varriount> Hm, but the thing about paths is that they are more than just a series of elements. You have path separators, and on Windows, long and short paths. |
19:57:15 | krux02 | That is something the old implementation also did not cover |
19:58:16 | * | Eyess is now known as eyes |
19:58:19 | FromGitter | <Varriount> Sure. But if someone is going to go to the trouble of modifying legacy code, they might as well improve the state of things. |
19:58:21 | * | eyes is now known as Eyes |
19:58:27 | krux02 | I did |
19:59:09 | * | Eyes is now known as await |
20:01:25 | * | bjz joined #nim |
20:01:47 | krux02 | Varriount: you only need to care about path separators, when you translate you path in something that the operating system needs to understand. Until then it can just be a list of strings. |
20:03:43 | FromGitter | <Varriount> krux02: What about drive handling? |
20:05:11 | * | Arrrr quit (Read error: Connection reset by peer) |
20:06:38 | krux02 | Varriount: can you please look at the commit? it is just a path as a string. You can put windows paths in a string, you can put unix style paths in a string. So it just works. |
20:08:52 | * | nhywyll joined #nim |
20:10:44 | krux02 | and just that you know, path normalization is not covered. If you have symlinks, or some '..' in your path, you paths can have duplicate elements. But it is not a bug, because the compilers generally don't care when they have duplicate elemnts in their path arguments. |
20:11:09 | FromGitter | <Varriount> Oh, I see. |
20:12:04 | FromGitter | <Varriount> I have to wonder to what extent the API's of various operating systems do path canonicalization. |
20:13:11 | krux02 | does it matter? |
20:15:23 | * | byte512 quit (Ping timeout: 264 seconds) |
20:16:00 | FromGitter | <Varriount> Well, If I type in `nim c ../test.nim`, I would rather not get an error. |
20:16:17 | FromGitter | <Varriount> But more than that, I'm just curious. |
20:18:15 | krux02 | I mean the same goes for URL. You can try to be smart for a URL class, and provide different fields for protocol and domain and subdomain. Or you can just use a string and don't care about the elements |
20:22:23 | * | gokr joined #nim |
20:25:30 | * | PMunch joined #nim |
20:43:34 | FromGitter | <Varriount> krux02: What I meant was, I wonder how `open`, `CreateFile`, etc handle path canonicalization. |
20:43:49 | FromGitter | <Varriount> It wasn't a criticism targeted at your changes. |
20:51:14 | * | mjanssen joined #nim |
21:00:45 | * | Trustable joined #nim |
21:08:02 | * | pregressive joined #nim |
21:11:42 | * | bjz quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
21:15:18 | * | carterza quit (Ping timeout: 276 seconds) |
21:20:18 | krux02 | Varriount: they probably just pass the string to the operating system |
21:20:58 | krux02 | so they probably just don't do "path canonicalization". I don't even know what that means to be honest |
21:22:09 | * | zetashift joined #nim |
21:23:19 | FromGitter | <Varriount> krux02: Collapsing dots, redundant path separators, etc |
21:23:46 | krux02 | yes, and what to do about them? |
21:24:00 | krux02 | let the operating system deal with them |
21:24:25 | krux02 | and when the operating system says, it's not ok forward that error to the user who created that path |
21:25:53 | subsetpark | I wouldn't mind a cute/weird mascot like Go... |
21:26:27 | FromGitter | <barcharcraz> I mean that's really just Rob Pike's wife being really good at drawing cute mascots |
21:26:30 | * | Matthias247 joined #nim |
21:26:36 | krux02 | subsetpark: what's cute about the go mascot? |
21:27:24 | FromGitter | <Varriount> @barcharcraz We have a mascot(s), a crown and a honey badger. |
21:27:25 | subsetpark | Its dumb googly eyes |
21:27:31 | FromGitter | <barcharcraz> hehe |
21:27:51 | subsetpark | Can we put dumb googly eyes on the crown? |
21:27:57 | FromGitter | <Varriount> Unfortunately the honey badger made small kids cry. |
21:28:14 | euantor | Still not as good as the Perl 6 butterfly |
21:28:38 | FromGitter | <Varriount> (Not to bash filwit's skills, the problem was that the image was too realistic) |
21:28:53 | subsetpark | The Perl 6 butterfly is rendered in a style that literally hasn't been appealing to anyone since 1978, which is a feat I am actually impressed by |
21:29:04 | krux02 | how about a block of butter with flies on top? Then we have fly butter. Can't beat that |
21:29:18 | euantor | https://en.m.wikipedia.org/wiki/File:Camelia.svg |
21:29:28 | FromGitter | <Varriount> https://upload.wikimedia.org/wikipedia/commons/thumb/8/85/Camelia.svg/2000px-Camelia.svg.png |
21:31:04 | FromGitter | <Varriount> Maybe I could hire a professional cartoonist to draw a mascot. |
21:33:43 | subsetpark | Nimrod was a mighty hunter - suggests cartoon mascot of a dude in a loincloth - makes me think of the characters from the old playstation game, Tail of the Sun. They were pretty cute/weird. |
21:33:44 | subsetpark | https://www.google.com/search?q=tail+of+the+sun&num=20&source=lnms&tbm=isch&sa=X&ved=0ahUKEwjGoMb_go7SAhWCwFQKHRyyCYEQ_AUICCgB&biw=1745&bih=895#imgrc=_ |
21:34:53 | rauss | I always picture the Green Day album. |
21:36:13 | krux02 | plastation one 3d graphics did not age very well |
21:37:50 | * | bjz joined #nim |
21:44:42 | * | bjz quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
21:45:20 | FromGitter | <barcharcraz> the days before perspective correct filtering and the zbuffer |
21:45:22 | FromGitter | <barcharcraz> good times |
21:45:26 | FromGitter | <barcharcraz> gooooooood times |
21:45:57 | krux02 | well, on pc there was perspective correct filtering |
21:46:04 | FromGitter | <barcharcraz> well yeah |
21:47:00 | krux02 | and it did not have these weird rounding errors that made 3d geometry wobble around when the camera moves |
21:47:18 | demi- | i think the crown is nice? |
21:47:39 | krux02 | I mean it is already a crown |
21:47:53 | krux02 | when there is an artist. The artist could try to make the crown look cool |
21:48:15 | FromGitter | <Varriount> https://thumbs.dreamstime.com/z/cartoon-animal-badger-illustration-55841969.jpg |
21:48:22 | FromGitter | <Varriount> There. Tack a crown on that. |
21:48:27 | krux02 | or you could create a contest and the person who wins has the honor that his artwork might become the official logo of nim |
21:48:49 | krux02 | (don't promise too much, when all submissions are crap don't force yourself to accept it) |
21:53:39 | FromGitter | <barcharcraz> I want a logo for my in progress sql library that's an octopus wearing a crown and reaching all inside a database |
21:55:30 | subsetpark | The crown is definitely nice... but it's not a *mascot* |
21:55:34 | subsetpark | It's just a logo |
21:56:04 | FromGitter | <barcharcraz> A mascot is something you can reasonably expect to end up in plush form |
21:56:21 | * | nhywyll quit (Quit: nhywyll) |
21:56:35 | Vladar | Print-n-cut crowns! |
21:56:37 | subsetpark | Though yes, I guess you could do the opposite of what most projects do with the mascot - instead of taking the language's mascot and theming it to fit your project, you make your own mascot and theme it to fit the language (ie, put a crown on it) |
21:56:54 | krux02 | Then I want a Cuthullu with a crown |
21:57:31 | krux02 | https://duckduckgo.com/?q=cthulhu+plush&iax=1&ia=images |
21:58:00 | Vladar | Actually, I'm pretty good with simple vector art |
21:58:09 | * | carterza joined #nim |
21:58:31 | FromGitter | <Varriount> @barcharcraz I dunno, a plush crown with eyes might be ok |
21:59:03 | FromGitter | <barcharcraz> I guess |
21:59:09 | Vladar | Btw, does C has a mascot? |
21:59:15 | FromGitter | <barcharcraz> I don't think so |
21:59:31 | krux02 | yes it has it is a big letter C |
22:00:04 | krux02 | it anyone taking this conversation serious? |
22:00:11 | krux02 | it doesn't matter. |
22:00:37 | rauss | ;_; |
22:01:25 | krux02 | rauss: you weren't even discussing a mascot |
22:01:28 | rauss | |\_/\_/| <-- crown |
22:02:41 | krux02 | (>°°)> <(°°<) |
22:02:45 | krux02 | not a mascot |
22:02:49 | * | nsf quit (Quit: WeeChat 1.7) |
22:02:49 | rauss | krux02: Of course it doesn't matter. But things like mascots or logos can make languages more endearing, and approachable. And something like a jagged crown makes the case that nim isn't as colorful or approachable, that it's for a different audience. Which can be a good thing. |
22:03:47 | krux02 | well yea, but before that kind of audience can be addressed, there are for more important things |
22:04:18 | rauss | Agreed. |
22:09:41 | * | rauss quit (Quit: WeeChat 1.7) |
22:32:52 | * | zetashift left #nim ("Leaving") |
22:37:29 | carterza | o/ |
22:40:04 | * | Vladar quit (Quit: Leaving) |
22:40:06 | subsetpark | Um - any idea why my linker would suddenly start failing? I was messing around with trying different compilers - cpp, cross-compiling to linux, whatever - and now when I compile with the normal settings I have been using, I get a linker error: `clang: error: linker command failed with exit code 1 (use -v to see invocation)` |
22:40:37 | subsetpark | Has Nim cached some flag I passed on the command line? |
22:41:43 | subsetpark | ah, it was because my cleanup script removed the wrong nimcache. Ok crisis averted! |
22:41:49 | carterza | krux02 - I know you explained this to me the other day but I can’t find our convo in the logs - could you tell me how to convert a quaternion to a mat4f using glm? |
22:43:23 | carterza | nevermind i found the convo |
22:44:16 | * | Kingsquee joined #nim |
22:54:06 | * | gokr quit (Ping timeout: 276 seconds) |
22:57:18 | * | Trustable quit (Remote host closed the connection) |
22:57:21 | * | couven92 quit (Quit: Good night!) |
22:58:40 | * | cjbest quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
23:03:25 | * | Matthias247 quit (Read error: Connection reset by peer) |
23:13:07 | * | pregressive quit (Remote host closed the connection) |
23:13:44 | * | pregressive joined #nim |
23:15:16 | * | pregressive quit (Read error: Connection reset by peer) |
23:15:40 | * | pregressive joined #nim |
23:17:05 | * | pregressive quit (Read error: Connection reset by peer) |
23:17:17 | * | pregressive joined #nim |
23:19:12 | * | pregressive quit (Read error: Connection reset by peer) |
23:19:38 | * | pregressive joined #nim |
23:20:16 | * | PMunch quit (Quit: leaving) |
23:21:47 | * | pregressive quit (Remote host closed the connection) |
23:22:04 | * | gangstacat joined #nim |
23:22:23 | * | pregressive joined #nim |
23:23:33 | * | pregress_ joined #nim |
23:23:33 | * | pregressive quit (Read error: Connection reset by peer) |
23:25:04 | * | pregress_ quit (Read error: Connection reset by peer) |
23:26:21 | * | vlad1777d quit (Quit: Leaving) |
23:26:33 | * | gangstacat quit (Client Quit) |
23:27:13 | * | xet7 quit (Quit: Leaving) |
23:32:44 | * | gangstacat joined #nim |
23:33:25 | * | rauss joined #nim |
23:36:30 | * | arnetheduck quit (Ping timeout: 252 seconds) |
23:42:53 | * | ftsf joined #nim |
23:43:52 | krux02 | carterza: Sorry for the late reply, I wrote in my fork a one call conversion. |
23:44:01 | carterza | thanks |
23:44:06 | carterza | I forgot you had done that too |
23:44:07 | carterza | and no problem |
23:53:30 | * | sz0 joined #nim |
23:53:48 | carterza | well my skeletal animation is producing something lol - http://imgur.com/a/iGFkU |
23:53:51 | carterza | just not what I’d like |