00:00:49 | * | Nobabs27 joined #nim |
00:43:51 | * | yglukhov joined #nim |
00:48:12 | * | yglukhov quit (Ping timeout: 260 seconds) |
01:19:08 | * | brson quit (Quit: leaving) |
01:19:29 | * | brson joined #nim |
01:27:35 | FromGitter | <Varriount> zachcarter: So what implementation did you end up using? |
01:28:11 | zachcarter | basically just using spawn and keeping track of the flow vars |
01:28:44 | FromGitter | <Varriount> zachcarter: How hard was it to code? |
01:28:55 | * | rauss joined #nim |
01:29:02 | zachcarter | wasn’t too bad but I’m still dealing with certain asset types, like texture atlases |
01:29:07 | FromGitter | <Varriount> I know @Araq will be happy that you're using spawn |
01:29:23 | zachcarter | they’re a pain in that they’re really a series of assets that need loading |
01:29:30 | zachcarter | but spawn was easy to use |
01:29:45 | zachcarter | the casts are a bit annoying |
01:29:48 | zachcarter | like - |
01:29:58 | zachcarter | let atlasInfo = cast[FlowVar[AtlasInfo]](assetLoadInProgress).`^`() |
01:30:08 | zachcarter | but I’m sure I could write a macro or a template to make that not so bad |
01:30:40 | FromGitter | <Varriount> Why did you need the casts? |
01:30:58 | FromGitter | <Varriount> I mean, why weren't those variables flowvars to begin with? |
01:31:56 | zachcarter | I guess I could turn them into FlowVars, but I had written all those types before I started using them with spawn |
01:32:03 | zachcarter | and FlowVars have a type |
01:32:11 | zachcarter | associated with them |
01:34:18 | FromGitter | <Varriount> Huh. I thought FlowVar types were generated from spawn. I didn't know you needed to define them separately. |
01:36:16 | zachcarter | I may very well be doing something incorrectly |
01:37:35 | zachcarter | I wish I could just do this with async / await |
01:37:39 | zachcarter | but I really don’t have a strong grasp on it |
01:37:58 | zachcarter | I guess the procedure that does the loading of the file itself has to be asynchronous |
01:38:18 | FromGitter | <Varriount> zachcarter: async/await Is single-threaded. |
01:38:28 | zachcarter | oh |
01:38:56 | FromGitter | <Varriount> For asset loading you probably want a concurrent approach. |
01:39:15 | zachcarter | right |
01:39:20 | zachcarter | which is what I’m doing now I believe |
01:39:50 | FromGitter | <Varriount> https://nim-lang.org/docs/manual.html#parallel-spawn |
01:40:45 | FromGitter | <Varriount> So, for example, you might have an "AssetObject" type, with variants for holding different kinds of assets |
01:41:13 | zachcarter | pretty much exactly what I have |
01:41:51 | FromGitter | <Varriount> And then have a sequence `seq[FlowVar[AssetObject]]` |
01:42:20 | zachcarter | ah okay |
01:42:21 | zachcarter | I just have |
01:42:25 | zachcarter | seq[AssetObject] |
01:42:57 | FromGitter | <Varriount> And you would use `spawn` to append results from an asset loading procedure into that sequence. |
01:43:50 | zachcarter | makes sense |
01:44:24 | FromGitter | <Varriount> Then you can use `^` to retrieve the value from the flowvar. |
01:44:57 | FromGitter | <Varriount> FlowVars are essentially like Promises or Futures - they hold a result that may not exist yet. |
01:45:04 | zachcarter | right |
01:45:54 | FromGitter | <Varriount> (I wish there was a proper, non-operator procedure to get the final result) |
01:47:45 | FromGitter | <Varriount> zachcarter: I'd be wary about casting to/from a flowvar. I'm surprised you're not getting data curruption |
01:48:07 | FromGitter | <Varriount> https://github.com/nim-lang/Nim/blob/master/lib/pure/concurrency/threadpool.nim#L99 |
01:48:23 | zachcarter | hmm |
01:49:08 | zachcarter | yeah I’m going to fix this now |
02:29:44 | ldlework | is this a good structure for a 2D BSP? https://gist.github.com/dustinlacewell/5bd54110f611b93f387a5f1aaf53558a |
02:36:29 | FromGitter | <Varriount> BSP = Binary Space Partitioning ? |
02:38:38 | FromGitter | <Varriount> ldlework: Wouldn't the "content" member of the "Leaf" variation be a sequence? |
02:39:18 | ldlework | Varriount, it will just refer to some view object which will know how to draw some window |
02:39:41 | ldlework | not sure why it would be a sequence |
02:40:34 | * | rauss quit (Quit: WeeChat 1.7) |
02:41:36 | FromGitter | <Varriount> ldlework: I was thinking nodes in a scenegraph |
02:41:50 | * | rauss joined #nim |
02:44:49 | ldlework | Varriount think tiling window manager |
02:45:48 | * | yglukhov joined #nim |
02:50:11 | * | yglukhov quit (Ping timeout: 260 seconds) |
03:05:25 | zachcarter | http://imgur.com/a/xEvYQ |
03:09:40 | FromGitter | <Varriount> zachcarter: \o/ |
03:09:52 | zachcarter | :D |
03:11:14 | FromGitter | <Varriount> zachcarter: Did you do the graphics? |
03:11:32 | zachcarter | nope! |
03:11:34 | zachcarter | they’re kenny's |
03:11:49 | zachcarter | https://kenney.nl/assets |
03:16:34 | ldlework | how do I default parameter as nil/ |
03:16:42 | ldlework | how do I set the type and specify the default at the same time |
03:17:11 | FromGitter | <Varriount> ldlework: Yes. |
03:18:02 | ldlework | what? |
03:18:47 | FromGitter | <Varriount> ldlework: `proc foo(parameter: ref Bar = nil)` |
03:19:57 | ldlework | thansk |
03:24:01 | ldlework | Varriount, this look right? https://gist.github.com/dustinlacewell/a72f967694ca8920e022611877b6c171 |
03:24:34 | ldlework | oh hmm no |
03:25:17 | ldlework | https://gist.github.com/dustinlacewell/a72f967694ca8920e022611877b6c171 there we go |
03:31:00 | ldlework | how do you tell if something is nil without crashing |
03:31:09 | FromGitter | <Varriount> isNil() |
03:32:50 | ldlework | oops "var result" |
03:32:52 | ldlework | ouch |
03:32:53 | ldlework | hard to spot |
03:34:20 | ldlework | nice |
03:34:45 | * | winnebagel joined #nim |
03:36:03 | * | [ui] joined #nim |
03:46:28 | ldlework | how does default equality work |
03:49:40 | ldlework | Varriount, if I remove the return statement here the test fails, https://gist.github.com/dustinlacewell/5ecf21397e3bbce3e1af7fda49d2e9d9 |
03:49:47 | ldlework | line 66 |
03:53:21 | ldlework | does that make any sense? |
03:55:08 | * | vlad1777d joined #nim |
04:02:50 | * | vlad1777d quit (Remote host closed the connection) |
04:07:03 | * | vlad1777d joined #nim |
04:10:01 | * | babs_ joined #nim |
04:12:33 | * | Nobabs27 quit (Ping timeout: 240 seconds) |
04:20:00 | * | vlad1777d quit (Remote host closed the connection) |
04:22:36 | * | vlad1777d joined #nim |
04:23:54 | * | vlad1777d quit (Remote host closed the connection) |
04:35:42 | * | zachcarter quit (Quit: zachcarter) |
04:36:46 | * | kunev quit (Ping timeout: 240 seconds) |
04:37:33 | * | kunev joined #nim |
04:47:58 | * | yglukhov joined #nim |
04:51:51 | ldlework | is there a better way to do, compiles((Leaf[string])root) |
04:52:26 | * | yglukhov quit (Ping timeout: 260 seconds) |
04:56:25 | ldlework | Why doesn't this work? https://gist.github.com/dustinlacewell/357da4321c041ff69d0503d6994b23af |
04:56:33 | ldlework | someoneeeeeee |
04:57:58 | ldlework | hmm |
04:58:18 | ldlework | doing compiles((any type at all)root) seems to be true |
04:58:21 | ldlework | wtf |
05:01:06 | ldlework | hmm interesting can't upcast... |
05:01:42 | ldlework | If you have an A B subtype relation |
05:01:46 | ldlework | and you have some type that stores A |
05:01:49 | ldlework | and you pass it a B |
05:01:59 | ldlework | and then somewhere else get the value back |
05:02:05 | ldlework | is there a way to use it as a B again? |
05:02:21 | ldlework | I feel like this is a pattern I suffer with chronically :D |
05:03:07 | * | ldlework scratches head |
05:04:06 | ldlework | you all just love to watch me squirm ;) |
05:06:44 | ldlework | I see, somehow `of` magically knows |
05:09:52 | ldlework | nice |
05:39:53 | * | winnebagel left #nim ("ii - 500 SLOC are too much") |
05:41:37 | * | sz0 joined #nim |
05:54:06 | ldlework | man you can really compact code with inheritance |
05:54:35 | ldlework | Holy Refactoring Batman! |
06:00:36 | FromGitter | <Varriount> ldlework: Sorry, what? |
06:01:05 | FromGitter | <Varriount> Were you not using inheritance before? |
06:07:57 | * | Vladar joined #nim |
06:12:56 | ldlework | Varriount how can I make this better, https://gist.github.com/dustinlacewell/d9a748b7bcc5e85094e84377da825a43 |
06:13:09 | ldlework | the implementations are exactly the same |
06:13:16 | * | babs_ quit (Quit: Leaving) |
06:14:01 | ldlework | oh it doesn't even work |
06:14:32 | ldlework | Varriount, read above about my problem regarding AB subtype relations |
06:14:35 | ldlework | and up-casting |
06:14:39 | ldlework | please |
06:17:24 | * | [ui] quit (Quit: Connection closed for inactivity) |
06:19:48 | ldlework | oh duh |
06:19:51 | ldlework | add another generic arg |
06:22:25 | * | nsf joined #nim |
06:27:50 | ldlework | noice |
06:33:15 | * | brson quit (Ping timeout: 260 seconds) |
06:44:30 | FromGitter | <Varriount> ldlework: I think I need to see more of the code first |
06:45:51 | FromGitter | <Varriount> Inheritance and generics don't work too well together. |
06:47:00 | FromGitter | <Varriount> Normally I'd suggest you use methods, but I don't know if they work with generics |
06:47:26 | euantor | Rust might have Nim beat, getting mentioned in batgirl: https://twitter.com/chasinglogic/status/850115493923086336 |
07:04:04 | * | rokups joined #nim |
07:05:15 | ldlework | Varriount: https://gist.github.com/dustinlacewell/8d6bec431ed977976bb40915c5428a52 \p/ |
07:07:03 | ldlework | There's a lot of casting in this version |
07:07:56 | ldlework | now to draw the structure :) |
07:11:13 | * | Trustable joined #nim |
07:11:49 | * | rauss quit (Quit: WeeChat 1.7) |
07:20:25 | * | chemist69 joined #nim |
07:26:45 | * | yglukhov joined #nim |
07:27:01 | * | yglukhov quit (Read error: Connection reset by peer) |
07:29:23 | * | yglukhov joined #nim |
07:30:05 | Araq | euantor: we shall be in batman then :-) |
07:30:10 | * | yglukhov quit (Remote host closed the connection) |
07:30:43 | * | yglukhov joined #nim |
07:30:46 | * | yglukhov quit (Remote host closed the connection) |
07:30:58 | * | yglukhov joined #nim |
07:48:23 | euantor | Araq: :) |
07:49:19 | Araq | https://www.youtube.com/watch?v=QELRiIeJY1U |
07:51:38 | ldlework | hehe |
08:01:19 | * | Trustable quit (Remote host closed the connection) |
08:07:32 | * | Arrrr joined #nim |
08:07:32 | * | Arrrr quit (Changing host) |
08:07:32 | * | Arrrr joined #nim |
08:30:13 | ldlework | http://i.imgur.com/DxkEKhT.png my BSP is working |
08:39:20 | * | cspar quit (Ping timeout: 264 seconds) |
09:15:34 | FromGitter | <evacchi> so @zachcarter: I've pushed a simple example inspired by your problem. build with `nimble loader` https://github.com/evacchi/nimoy/blob/master/examples/loader.nim |
09:29:19 | subsetpark | ldlework: what WM is that? |
09:29:59 | * | Andris_zbx joined #nim |
09:31:53 | ldlework | subsetpark: its not a vm, its just a bsp I'm writing in nim |
09:31:58 | ldlework | unless you mean my actual vm, then qtile |
09:32:26 | subsetpark | yeah, i meant your actual vm - i like the asdf-based desktops |
09:45:09 | * | smt_ joined #nim |
09:48:23 | * | smt quit (Ping timeout: 240 seconds) |
09:54:50 | * | zachcarter joined #nim |
09:56:12 | * | smt_ is now known as smt |
10:07:42 | * | PMunch joined #nim |
10:13:36 | * | vlad1777d joined #nim |
10:20:38 | * | vlad1777d quit (Remote host closed the connection) |
10:26:02 | * | couven92 joined #nim |
10:27:42 | * | Vladar quit (Quit: Leaving) |
10:29:37 | couven92 | Araq, can you declare types using templates... I cannot seem to get mine to work... https://pastebin.com/2fRrkVGR and https://pastebin.com/Bzfctjcd |
10:35:22 | Araq | couven92: can't work |
10:35:41 | Araq | nim is not homoiconic enough for this |
10:35:50 | Araq | but you can use a macro |
10:36:35 | couven92 | ok... parsing the AST... right, after learning template, now I have do more reading... Thanks Araq! :) |
10:37:20 | couven92 | PMunch, told how excited he was after doing that wxnim macro... so I'm looking forward to it! :D |
10:40:58 | couven92 | can the last argument to a macro still be a block if it is untyped? Like with templates (shown here: https://nim-lang.org/docs/manual.html#templates-passing-a-code-block-to-a-template ) |
10:44:42 | PMunch | couven92, if you look at the wxnim macro it does that |
10:44:51 | couven92 | ok thx |
10:55:57 | arnetheduck | Araq, https://github.com/nim-lang/Nim/pull/5656? |
10:56:21 | Araq | arnetheduck: will merge it later ok? |
10:56:39 | arnetheduck | great, thanks.. mainly wanted to know if it'll go in |
10:57:04 | arnetheduck | have some other stuff that depends on it, sort of |
10:58:31 | Araq | I've a growing collection of nimble package tests that are becoming another acceptance criterion before PRs can be merged |
10:59:02 | Araq | I hope I can update travis this weekend to check for more things |
11:06:29 | arnetheduck | hope those things run in parallel then, because the tests are taking quite long as-is |
11:07:00 | arnetheduck | but good development nonetheless |
11:07:43 | arnetheduck | osx is missing from the automated runs, no? |
11:09:21 | Araq | they are run on osx but travis' osx runner has a bug |
11:09:33 | Araq | it reports "failure" even though everything is green. |
11:09:51 | Araq | so we need to look at it with our own eyes :-( |
11:10:46 | Araq | I think travis' whole architecture is a bunch of horrible bash scripts :-) |
11:12:33 | euantor | So just bash scripts then, I've yet to see a "nice" bash script :P |
11:13:27 | Araq | well there is still the distinction between "working and horrible" and "broken and horrible" :P |
11:14:31 | Araq | and then there is the usual "working as long as your filenames have no space and horrible" bash script |
11:16:23 | arnetheduck | whitespaceisoverratedanyway |
11:37:53 | FromGitter | <Danielez> Hello is there a tool to translate python to nim? or even a first approximation of this to then work on? |
11:41:33 | FromGitter | <TiberiumPY> not yet :) |
11:41:42 | FromGitter | <TiberiumPY> but it's not hard to translate simple python |
11:41:47 | FromGitter | <TiberiumPY> without any dynamic features |
11:41:48 | FromGitter | <andreaferretti> a first approximatino is often just copying the source :-) |
11:41:52 | FromGitter | <TiberiumPY> yeah |
11:42:05 | FromGitter | <andreaferretti> and then adding types |
11:42:09 | FromGitter | <TiberiumPY> I did that for a few times when I need to translate simple python script :D |
11:44:39 | FromGitter | <Danielez> Ok, thanks |
11:45:06 | FromGitter | <TiberiumPY> but yeah, maybe in the future we'll see this tool like pas2nim, but py2nim |
11:45:43 | FromGitter | <TiberiumPY> @Danielez but translating big python frameworks/programs is not easy |
11:45:57 | FromGitter | <TiberiumPY> because there's almost 100% chance they contain a lot of dynamic features |
11:46:22 | FromGitter | <TiberiumPY> (btw, overloading in Nim looks better for me than using isistance() in Python) |
11:46:28 | Araq | https://forum.nim-lang.org/t/2705#16724 |
11:46:52 | Araq | it can be used to translate Python to Nim, I hope |
11:49:37 | FromGitter | <TiberiumPY> oh, there's "auto" in nim? |
11:49:49 | FromGitter | <TiberiumPY> I didn't know about it :D |
11:50:41 | * | BitPuffin|osx joined #nim |
11:51:44 | FromGitter | <Danielez> Thank you @Araq and @TiberiumPY |
11:55:16 | FromGitter | <TiberiumPY> @Araq so you can use ```auto``` to get inferred types after first compilation (if you translate from python)? |
11:58:11 | FromGitter | <TiberiumPY> or even if you're lazy :D |
12:00:36 | couven92 | Ok, I have now created a macro as Araq suggested: https://pastebin.com/ggtYWkb4 |
12:00:41 | couven92 | Now when I compile I get: https://pastebin.com/ggtYWkb4 |
12:00:50 | couven92 | sry, SIGSEGV: Illegal storage access. (Attempt to read from nil?) |
12:01:19 | couven92 | what am I doing wrong now... How can I debug my macro? |
12:03:57 | couven92 | https://pastebin.com/P5a2qtNu (added what I expect the macro to produce) |
12:04:09 | FromGitter | <evacchi> genuine question: why are pragmas (mostly) postfix ? I find this a bit hard to read and sometimes even remember where to put them :P (besides they're not even *always* postfix) |
12:04:48 | FromGitter | <evacchi> (I understand discussions about syntax are mostly sterile but I'm genuinely interested) |
12:07:46 | * | zachcarter quit (Quit: zachcarter) |
12:12:39 | Araq | evacchi: initially pragmas only existed for procs and here the syntax is nice enough. and then they were patched into other places |
12:13:14 | Araq | also it wasn't obvious back then they would become heavily used -.- |
12:16:54 | FromGitter | <evacchi> :P |
12:17:37 | FromGitter | <evacchi> @araq: wouldn't they "scan" better if they were prefix ? |
12:17:46 | * | PMunch quit (Ping timeout: 240 seconds) |
12:17:52 | FromGitter | <evacchi> I think it might make the language more "regular" |
12:18:01 | FromGitter | <evacchi> there's quite a few places where they already are prefix |
12:18:57 | FromGitter | <evacchi> like, you know: `@thread proc foo()` or `[thread] proc foo() ` (*cough cough* annotations *cough*) |
12:19:12 | FromGitter | <Varriount> @evacchi I've suggested that to. It would certainly make pragma-heavy procedures more readable... |
12:19:26 | FromGitter | <Varriount> *too |
12:19:27 | FromGitter | <evacchi> would love that |
12:19:45 | FromGitter | <evacchi> but you know, I understand this would not be high on a priority list |
12:28:11 | FromGitter | <Varriount> @evacchi Right now there would be syntactic ambiguity. |
12:29:04 | FromGitter | <Varriount> Take for example `{.experimental.}`, which is a standalone pragma used to enable experimental features in a module |
12:29:40 | FromGitter | <Varriount> What would happen if that pragma was placed right before a procedure? |
12:31:04 | FromGitter | <Varriount> It would not only be a tough case for the compiler to handle, it's ambiguous to those reading code. |
12:31:19 | * | PMunch joined #nim |
12:33:14 | Araq | huh? I can see {..} are not exactly sexy, but prefix syntax? seriously? |
12:33:30 | * | shashlick quit (Ping timeout: 260 seconds) |
12:33:37 | Araq | @random @crap @Idontcareabout proc finallyTheNameHere() |
12:33:55 | Araq | important stuff should come first, not last. :P |
12:34:13 | FromGitter | <Varriount> @araq between effects, locks, and macros, a procedures pragma section can get really big |
12:34:16 | * | shashlick joined #nim |
12:34:31 | Araq | varriount: the docgen folds it fwiw |
12:34:59 | FromGitter | <Varriount> That's great. Text editors don't. |
12:35:08 | Araq | they could :P |
12:35:32 | Araq | and since you're the author of the sublime plugin, you know what you've got to do now ;-) |
12:35:51 | FromGitter | <Varriount> And github? Paste sites? |
12:36:33 | FromGitter | <Varriount> Bah, I've publicly stated I have no time for NimLime, and won't have time until about a year from now |
12:37:05 | Araq | I planned to take over NimLime but I don't exactly have much time either |
12:37:51 | Araq | so what? it's an optional feature and Nim with its current pragma syntax is not exactly hard to read. on github or elsewhere. |
12:38:16 | Araq | also, effects are inferred, so the issue is more severe for the generated docs |
12:38:28 | Araq | which do fold already. |
12:38:43 | FromGitter | <Varriount> It just makes a procedure ugly when the pragma section crosses more than one line |
12:39:11 | FromGitter | <Varriount> Besides, users shouldn't have to rely on editors to cover up a languages warts. |
12:39:34 | Araq | it's not a "wart". |
12:39:43 | Araq | it's a personal dislike by some people. |
12:40:03 | Araq | and you seem to be more concerned about the placement of the '=' afaict |
12:40:06 | Araq | proc foo() = |
12:40:15 | Araq | {.raises: [], ....} |
12:40:27 | Araq | echo "would be an improvement?" |
12:40:57 | FromGitter | <Varriount> Possibly. |
12:41:35 | couven92 | Araq, PMunch, how do I debug a macro? Because my macro causes a SIGSEGV illegal storage access during compilation, and I have no idea of where it goes wrong... https://pastebin.com/P5a2qtNu if you could take a look... Additionally, how do I add a `*` to the type name (1st arg) to make the type it generates exporable? Do I have to write another variant of the macro for that? |
12:42:08 | Araq | couven92: please file a github issue. debugging a macro is usally done by 'echo repr result' |
12:42:24 | couven92 | ok, thx |
12:42:33 | Araq | but not if the fucking compiler crashes :-( |
12:43:31 | PMunch | couven92, any idea where the SIGSEGV occurs? |
12:43:42 | couven92 | nope |
12:43:51 | PMunch | And for any syntax stuff you should really look at dumpTree |
12:44:04 | couven92 | ah ok... will try |
12:44:09 | PMunch | So dumpTree whatever you want to create and then look at what that gives you :) |
12:44:47 | PMunch | But be warned, it can be a bit buggy sometimes (at least in the past) so I would copy the result from dumpTree over into a text-file and then remove it from the program |
12:45:24 | FromGitter | <evacchi> @araq I just find it strange that all the modifiers which are kind of part of the signature come after the whole signature; I'm accustomed to read modifiers before the `proc`/method declaration |
12:45:28 | PMunch | couven92, it's not the empty add statement on line 8 which causes it? |
12:45:43 | FromGitter | <evacchi> like `private something something void foo()` |
12:45:46 | couven92 | oh |
12:45:56 | couven92 | PMunch, that might be... let's see |
12:47:01 | FromGitter | <evacchi> besides, since it comes after the `):` looks a bit like its something pertaining to the return value |
12:47:15 | Araq | evacchi: yeah, I don't like it. I never got used to C based syntax really, even after years. it's ugly. |
12:47:29 | Araq | and backwards. |
12:50:18 | couven92 | Araq, echo repr is a BIG help! thx! PMunch: dumpTree doesn't do it for me :( But yes, the empty add was the issue, now I have some other things that I need to work out, but now I know what I get... :P |
12:50:58 | FromGitter | <evacchi> I see your point, but I don't think that you really don't care about the random crap in `@random @crap proc foo()` :P |
12:51:02 | PMunch | Doesn't do what? Doesn't show the *? |
12:51:18 | FromGitter | <evacchi> modifiers such as thread, and gcsafe change quite a bit the contexts where the proc can be used |
12:51:24 | PMunch | The error really shouldn't end in a SIGSEGV though so you should still create an issue :) |
12:51:29 | FromGitter | <evacchi> so you *should* care about those |
12:53:54 | * | zachcarter joined #nim |
12:54:29 | PMunch | Araq, I like the idea of putting pragmas after the = makes it easier to read at least, if not a bit confusing semantically. |
12:57:06 | FromGitter | <evacchi> @PMunch at least that would make it clear that it changes the *body* of a proc; but then again, how to declare the pragma of a higher-order proc in a parameter list? |
12:57:58 | FromGitter | <evacchi> i mean: `proc foo() = {.blah.}` `proc bar(f : proc(){.blah.})` <-- no `=` here! |
12:58:10 | PMunch | Yeah |
12:58:16 | PMunch | Same for forward declaration of procs |
12:58:30 | PMunch | Where you don't have a = |
12:58:39 | PMunch | That would be a bit confusing |
12:58:42 | FromGitter | <evacchi> yes |
12:59:35 | couven92 | PMunch, ok will do... And no the * after the type name (for export) still does not work... So I'll just create a second macro for that... |
12:59:52 | FromGitter | <evacchi> in the prefix form, it's pretty common in — oh! the horror! — in Scala/Java to put those on two lines: ⏎ ⏎ ```@random @crap ⏎ def foo() = ⏎ ...``` [https://gitter.im/nim-lang/Nim?at=58e78d498fcce56b20dc440c] |
13:00:05 | FromGitter | <evacchi> :P |
13:00:14 | FromGitter | <Varriount> I just want something that makes it more likely `proc ` and `=` are on the same line |
13:00:33 | PMunch | Oh wait, were you trying to do it in the name part when defining the function? |
13:00:47 | PMunch | That would make it "proc `myFunc*`()" |
13:01:06 | PMunch | So the name would be myFunc* and now be an exposed procedure |
13:01:45 | FromGitter | <TiberiumPY> @evacchi i like this style, it's like decorators in python |
13:02:09 | FromGitter | <evacchi> that was the idea, yes. in fact, macro pragmas are kind of like decorators in python |
13:02:52 | * | bjz joined #nim |
13:03:22 | FromGitter | <evacchi> and it would probably work for type declarations as well like `type @bar Foo` |
13:07:17 | FromGitter | <evacchi> besides pragmas such as `{.experimental.}` that come at the top of the module could be blessed with ad-hoc syntax; that would avoid ambiguities |
13:07:24 | FromGitter | <evacchi> anyway, just my 2c |
13:43:00 | * | smt quit (Read error: Connection reset by peer) |
13:47:07 | couven92 | ok, PMunch, Araq, now it has gotten a litte more complex: https://pastebin.com/NmTdM41s How do I convert the StmtList I get from the block in Line 43, to be a RecList that I need for the object parameters? |
13:47:33 | couven92 | or maybe I should reparse the reclist argument as a nnkRecList node? |
13:50:14 | PMunch | Just write a loop that creates a RecList from the StmtList |
13:50:25 | PMunch | for r in stmtlist: |
13:50:51 | PMunch | reclist.add(Record(r[0],r[1][0])) |
13:50:56 | PMunch | Or something like that |
13:51:42 | PMunch | That's just pseudo-code by the way |
13:52:46 | couven92 | PMunch, the object parameters list can be very complex: https://nim-lang.org/docs/macros.html#statements-type-section |
13:53:32 | PMunch | Ah.. |
13:53:44 | PMunch | And you can't just add it untyped? |
13:54:01 | * | smt joined #nim |
13:55:45 | couven92 | Well in the macro implementation it is a NimNode, not untyped |
14:12:06 | * | bjz quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
14:18:53 | * | bjz joined #nim |
14:21:45 | * | rauss joined #nim |
14:42:44 | couven92 | Araq, how do I call another macro inside a macro? |
14:43:13 | Araq | you ... call it? |
14:43:31 | Araq | just like you would call a .compileTime proc |
14:44:03 | couven92 | doesn't work... it says that the arguments don't match, expected string but got NimNode |
14:44:21 | Araq | getAst m(...) |
14:44:41 | FromGitter | <andreaferretti> I think maybe you don't want to call it, but generate a call to it |
14:44:48 | FromGitter | <andreaferretti> which will eventually be compiled again |
14:45:06 | Araq | that's possible, or u use getAst |
14:46:03 | Araq | which works by chance but since I'm aware of it, it will make it into the spec |
14:46:53 | Araq | I would extract the common logic in a .compileTime proc that is used by both macros |
14:48:20 | Araq | andreaferretti: .immediate templates and macros all have untyped parameters, the types are lies |
14:48:42 | Araq | so if it works today with .immediate, it should also work with all parameters 'untyped' |
14:48:54 | FromGitter | <andreaferretti> this is quite bizarre |
14:49:02 | FromGitter | <andreaferretti> so the use case is the following |
14:49:14 | Araq | well .immediate is deprecated for a reason. |
14:49:15 | FromGitter | <andreaferretti> you have an expression and you want to do pattern matching on it |
14:49:31 | FromGitter | <andreaferretti> so you need to know the type of the expression |
14:49:48 | FromGitter | <andreaferretti> because, say, you want to know how the fields are called |
14:50:00 | FromGitter | <andreaferretti> or what are the possibilities in a variant type |
14:50:13 | FromGitter | <andreaferretti> on the other hand, the body of the pattern matching will be untyped |
14:50:29 | FromGitter | <andreaferretti> because, well, it is not well formed in the first place |
14:50:39 | FromGitter | <andreaferretti> and our task is exactly to rewrite it |
14:51:02 | FromGitter | <andreaferretti> so I am not sure how I can use an untyped parameter for the expression |
14:52:01 | FromGitter | <andreaferretti> uh sorry, I am talking about the `match` macro |
14:52:12 | Araq | macro match(pattern: typed; body: untyped) |
14:52:13 | FromGitter | <andreaferretti> but now I see the issue in the `variant` macro |
14:52:26 | * | bjz quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
14:53:02 | FromGitter | <andreaferretti> that one does not need the type on `e` |
14:53:09 | FromGitter | <andreaferretti> turns out it works fine this way |
14:53:14 | FromGitter | <andreaferretti> great! :-) |
14:53:22 | FromGitter | <andreaferretti> I can remove immediate |
14:54:26 | Araq | yeah, the language is much better without .immediate |
14:54:46 | Araq | and there are no known cases where the workaround wasn't easy. |
14:54:53 | FromGitter | <andreaferretti> I don'think I was using it elsewhere |
14:57:17 | * | bjz joined #nim |
15:03:15 | * | couven92 quit (Quit: Disconnecting) |
15:05:46 | FromGitter | <couven92> Hmm... now I'm really amazed: https://pastebin.com/Jh5ZgL19 it produces totally valid Nim code, but still the compiler complains and states: `test.nim(42, 18) Error: illformed AST: {.importC: "ULONG_PTR", header: "<Windows.h>".}` What happened here Araq? |
15:07:53 | FromGitter | <andreaferretti> try to write that and use https://nim-lang.org/docs/macros.html#dumpTree.m,untyped to see the generated tree |
15:08:00 | FromGitter | <andreaferretti> and compare that one with yours |
15:08:16 | FromGitter | <andreaferretti> maybe you are missing some node that is not shown in the source |
15:08:23 | FromGitter | <couven92> @andreaferretti ok, will try |
15:08:30 | FromGitter | <andreaferretti> such as statement sequence or such |
15:09:00 | cheatfate | nnkEmpty nodes is also important, dont try to miss it |
15:11:34 | FromGitter | <couven92> Uhm, how do I dump the results of the macro? |
15:11:51 | def- | couven92: echo result.repr at the end of macro |
15:13:13 | * | bjz quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
15:13:18 | FromGitter | <couven92> def-, that gives me the source the macro produces, not the AST tree dump |
15:13:33 | FromGitter | <andreaferretti> echo result.treeRepr |
15:13:39 | FromGitter | <couven92> ah |
15:14:40 | FromGitter | <couven92> ok, the whenStmt needs to be in a StmtList... make sense |
15:14:56 | * | vlad1777d joined #nim |
15:21:29 | zachcarter | doesn’t https://github.com/oprypin/nim-random/blob/master/random.nimble clash with https://nim-lang.org/docs/random.html in terms of module names? |
15:23:12 | Araq | it does, so use a path to disambiguate |
15:23:18 | * | Varriount|Mobile joined #nim |
15:23:34 | Araq | import oprypin / random or something |
15:23:54 | zachcarter | ah okay |
15:23:55 | Araq | or import random / random |
15:29:01 | * | Vladar joined #nim |
15:35:32 | zachcarter | not sure how to do that with a nimble dependency |
15:35:35 | zachcarter | neither resolve |
15:41:55 | * | onionhammer quit (Ping timeout: 240 seconds) |
15:42:00 | * | Andris_zbx quit (Remote host closed the connection) |
15:42:57 | * | onionhammer joined #nim |
15:51:15 | dom96 | IIRC disambiguating between stdlib and nimble packages is still not possible in certain cases. There is a bug for this on GitHub |
15:52:02 | zachcarter | ah okay |
15:52:16 | FromGitter | <couven92> Could we prefix nimble packages with nimble / |
15:52:37 | FromGitter | <couven92> Since the compiler has to be nimble aware anyways? |
15:53:14 | FromGitter | <couven92> Breaking change though... :/ |
15:53:42 | dom96 | Here is the relevant issue https://github.com/nim-lang/Nim/issues/2819 |
15:55:18 | demi- | packages should be namespaced |
15:55:36 | * | bjz joined #nim |
15:55:45 | demi- | it is really up to the third party devs to not pick package names that don't conflict with the stdlib |
15:56:57 | dom96 | The random package was introduced before the 'random' module was added to the stdlib. |
15:57:12 | FromGitter | <couven92> demi- what about multiple package authors? |
15:57:27 | dom96 | The standard library will evolve, who knows what modules will be in it in 2 years |
15:57:46 | dom96 | People may have private packages that we are not aware of that will conflict with it. |
15:57:50 | demi- | i believe python solves this by having syntax for `import foo as bar` |
15:58:07 | dom96 | So it's not even just a case of making sure the new stdlib modules don't conflict with public packages. |
15:58:38 | dom96 | Doesn't that only rename the import? |
15:59:04 | dom96 | 'foo' could still be in the importing module's directory, in a package or in the stdlib. |
15:59:41 | demi- | couven92, not sure i follow what you mean |
16:00:22 | demi- | dom96: ¯\_(ツ)_/¯ most ecosystems i know of follow the pattern of "third party devs will have to deal with it" |
16:00:38 | dom96 | lol |
16:00:43 | dom96 | we could take this stance too |
16:01:01 | dom96 | But I don't think it's a good idea |
16:01:16 | demi- | yeah it isn't great, it is just the most common approach i've seen |
16:01:39 | dom96 | It would be nice if the `random` package was renamed as a good-enough short-term fix though. |
16:02:53 | demi- | dom96: you could probably do something like add a linting/validation step to nimble to have it validate against name classes with other packages |
16:03:20 | demi- | that is viable since we are using a centralized package repo |
16:03:28 | dom96 | I'm not sure how that would help |
16:04:09 | demi- | well it would allow devs to know that their package may conflcit with an existing third party or system package and thus be rejected from the a merge request |
16:04:11 | dom96 | You mean Nimble should verify it when installing packages? |
16:04:58 | dom96 | For the packages repo I could add that sure, but it wouldn't help with future additions to the stdlib |
16:05:32 | demi- | i mean if i could run `nimble lint` before i `nimble publish`d and it said "hey you are using the module name 'random', this conflicts with the stdlib module 'random', you should rename to something else" that would be helpful |
16:06:18 | demi- | or if someone submits a wrapper for a C library, one already exists with the same name, maybe rename or confer with that package owner about joint work |
16:11:14 | * | yglukhov quit (Remote host closed the connection) |
16:12:25 | dom96 | It would be helpful, but it wouldn't have helped prevent the situation with the 'random' package. |
16:13:41 | demi- | true, but that is something that is unavoidable without metrics of the packages that are available |
16:14:11 | * | bjz quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
16:14:29 | dom96 | Indeed, so a syntax to disambiguate such imports is needed. |
16:19:35 | * | yglukhov joined #nim |
16:24:26 | * | yglukhov quit (Ping timeout: 260 seconds) |
16:31:20 | * | zachcarter quit (Ping timeout: 268 seconds) |
16:55:15 | dom96 | Not sure if Travis or my fault https://travis-ci.org/nim-lang/nimble/builds/219753897#L675 |
16:55:19 | dom96 | But WTF |
16:55:52 | dom96 | bah, I thought it would create a new build if I restart it. |
16:56:03 | dom96 | In any case, it gave a "Out of memory" error. |
17:00:42 | PMunch | Seems to be chugging along fine so far |
17:02:06 | * | Matthias247 joined #nim |
17:03:47 | demi- | dom96: i'm still seeing high memory usage with jester |
17:04:23 | * | yglukhov joined #nim |
17:04:30 | dom96 | even with mark and sweep and/or boehm? |
17:05:17 | demi- | mark and sweep |
17:06:34 | dom96 | That sucks, any chance you could reproduce the leak? |
17:06:52 | demi- | how do you mean? |
17:08:56 | dom96 | Come up with something I can run to reproduce the high memory usage? |
17:10:04 | demi- | well the code is pretty simple, since it is only doing static file hosting; wouldn't that indicate this is traffic related? |
17:12:56 | dom96 | Well... it seems to happen slowly |
17:13:14 | dom96 | So figuring out what the problem is won't be easy |
17:13:24 | dom96 | I'm wondering if there is any way to speed up the process |
17:17:46 | dom96 | You can also try using jester's devel branch, it handles static files a little bit differently. |
17:18:27 | dom96 | But if anything it might speed up the memory growth. It would still be interesting though. |
17:26:55 | * | yglukhov quit (Remote host closed the connection) |
17:38:08 | * | tax joined #nim |
17:47:38 | * | brson joined #nim |
17:50:54 | * | yglukhov joined #nim |
17:59:21 | * | zachcarter joined #nim |
18:00:05 | * | gokr joined #nim |
18:03:56 | * | zachcarter quit (Ping timeout: 264 seconds) |
18:04:26 | * | sz0 quit (Quit: Connection closed for inactivity) |
18:11:51 | * | Trustable joined #nim |
18:34:30 | dom96 | unmarshalling an object variant sure is fun |
18:46:25 | * | fvs joined #nim |
18:46:45 | fvs | hi, is it possible to convert a seq to an array? |
18:48:37 | dom96 | hello, why do you wish to do that? |
18:53:08 | * | BitPuffin|osx quit (Ping timeout: 264 seconds) |
18:54:01 | fvs | dom96, to pass as parameter to dll |
18:54:27 | dom96 | fvs: addr seq[0] |
18:54:31 | dom96 | Is what you want I think. |
18:58:25 | cheatfate | fvs, addr(sequence[0]) |
18:58:42 | cheatfate | but GC_ref() it before |
18:58:50 | cheatfate | or even better use system.protect() |
19:17:27 | Arrrr | protect? is that new? |
19:17:30 | fvs | thanks, I need to pass it as a ptr, so I guess > var aptr: ptr T = cast[ptr T](seq[0].addr) |
19:19:35 | cheatfate | Arrrr, 0.14+ i think |
19:20:40 | dom96 | fvs: You don't need the cast |
19:21:14 | dom96 | or at least you shouldn't need it if your DLL is wrapped well. |
19:33:18 | * | Arrrr quit (Quit: Leaving.) |
19:40:08 | fvs | cheatfate, to confirm first protect and later "dispose" to GC? |
19:40:26 | cheatfate | fvs, yeah |
19:43:38 | * | Varriount|Mobile quit (Read error: Connection reset by peer) |
19:43:44 | * | Varriount|Phone joined #nim |
19:53:24 | FromGitter | <Varriount> Hm. All protect() seems to do is guard against some sort of thread condition. |
19:58:27 | * | libman joined #nim |
20:02:16 | * | rokups quit (Quit: Connection closed for inactivity) |
20:04:29 | * | gokr quit (Quit: Leaving.) |
20:11:59 | * | rauss quit (Ping timeout: 246 seconds) |
20:13:10 | * | rauss joined #nim |
20:13:55 | ldlework | can you write a general converter? |
20:18:30 | * | BitPuffin|osx joined #nim |
20:20:06 | * | couven92 joined #nim |
20:21:06 | * | vlad1777d quit (Quit: Leaving) |
20:29:11 | fvs | to convert what? |
20:30:38 | fvs | celsius to fahreheit? |
20:37:17 | * | tinAndi joined #nim |
20:39:19 | * | yglukhov quit (Remote host closed the connection) |
20:42:16 | ldlework | Error: identifier expected, but found 'texture.info.size.w' ?? |
20:42:25 | ldlework | what does this mean? |
20:42:39 | ldlework | result.w = fmod(texture.info.size.w, tile_size.w) |
20:47:15 | * | yglukhov joined #nim |
20:48:12 | * | bjz joined #nim |
20:54:21 | * | rauss quit (Quit: WeeChat 1.7) |
20:57:30 | * | nsf quit (Quit: WeeChat 1.7) |
21:01:11 | ldlework | type Point2D[T: int|float]* = object |
21:01:14 | ldlework | x, y: T |
21:01:23 | ldlework | Error: implementation of 'Point2D' expected |
21:01:25 | ldlework | What does this mean |
21:03:35 | FromGitter | <Varriount> On what line is the compiler throwing that error? |
21:04:27 | ldlework | the first |
21:04:51 | ldlework | ah its the * |
21:05:07 | ldlework | bad error message :) |
21:05:49 | * | Trustable quit (Remote host closed the connection) |
21:13:54 | * | tinAndi quit (Quit: ChatZilla 0.9.93 [Firefox 52.0.2/20170323105023]) |
21:21:31 | ldlework | are basic non-ref objects covered anywhere? |
21:21:56 | ldlework | how do I create an instance of a `type Foo = object ..` ? |
21:22:33 | dom96 | Foo() |
21:24:07 | ldlework | no |
21:24:23 | ldlework | Error: object constructor needs an object type |
21:24:35 | FromGitter | <Varriount> Or just declare a variable. Unless they are located in a reference object, object types will be stored on the stack, and initialized to zero. |
21:25:15 | FromGitter | <Varriount> `var x: Foo`, `x.bar` |
21:25:35 | ldlework | attempting to call undeclared routine: 'left=' |
21:26:54 | FromGitter | <Varriount> ldlework: Could you just show us all your code? |
21:27:41 | ldlework | https://gist.github.com/dustinlacewell/16551703767efd32411c6782f79016be |
21:29:28 | FromGitter | <couven92> dom96, I am working on SChannel btw, having lots of fun with the FFI... But my mum's cat heavily disagrees with how I spend my time! Difficult to code when she lies down on top the keyboard! :D |
21:29:54 | dom96 | couven92: hehe, great :) |
21:30:14 | dom96 | I'm writing a macro to deserialize JSON into a type. |
21:30:26 | dom96 | Not as easy as I thought it would be |
21:30:32 | FromGitter | <Varriount> ldlework: https://glot.io/snippets/eoq7v62lqn |
21:30:51 | FromGitter | <Varriount> dom96: Might want to take a look at NimYAML |
21:31:05 | ldlework | Varriount sure but what's my problem? |
21:31:49 | dom96 | Varriount: Doesn't it work the same way as the marshal module? |
21:34:14 | * | Vladar quit (Quit: Leaving) |
21:34:55 | ldlework | I'm so confused |
21:36:42 | dom96 | ldlework: export the fields, maybe? |
21:37:01 | ldlework | Error: illformed AST: utils.Region[] |
21:37:06 | ldlework | O_O |
21:37:46 | FromGitter | <Varriount> ldlework: *All* of your code? |
21:37:59 | ldlework | dom96: you are the winner |
21:38:20 | ldlework | but thank you Varriount |
21:38:58 | ldlework | I wonder if the compiler could know that the field of that name exists but isn't exported |
21:39:02 | ldlework | and offer the advice |
21:40:54 | * | onionhammer quit (Read error: Connection reset by peer) |
21:41:15 | * | onionhammer joined #nim |
21:50:56 | ldlework | main.nim(124, 18) Error: invalid type: 'T' in this context: 'proc (app: App): GameScene' |
21:51:23 | ldlework | function isn't even generic |
21:55:05 | ldlework | Varriount, here is all the code: https://gist.github.com/dustinlacewell/566dfc079cd5bbc686c69281263994a3#file-main-nim-L124 |
21:57:06 | * | Varriount|Phone quit (Quit: AndroIRC - Android IRC Client ( http://www.androirc.com )) |
21:58:04 | ldlework | I don't know what this error means |
21:59:25 | ldlework | ugh |
22:02:09 | ldlework | ohh |
22:04:02 | dom96 | types are generic? |
22:08:34 | ldlework | back in action! |
22:09:34 | ldlework | its too bad there is no easy way to create a new non-ref on a single line |
22:09:39 | ldlework | IE, struct literals.. |
22:09:51 | * | yglukhov quit (Remote host closed the connection) |
22:10:12 | dom96 | there is if you define both |
22:10:22 | ldlework | ? |
22:10:28 | dom96 | type FooObj = object; FooRef = ref FooObj |
22:10:51 | ldlework | and then? |
22:11:54 | dom96 | FooObj()? |
22:12:08 | ldlework | I don't get it, why is it required to define FooRef? |
22:12:48 | FromGitter | <stisa> Idlework: are you looking for something like https://nim-lang.org/docs/manual.html#types-object-construction ? |
22:13:02 | FromGitter | <couven92> uhm, goto another case in Nim? Possible? How? |
22:13:41 | dom96 | ldlework: I dunno, my assumptions are probably wrong. |
22:13:44 | dom96 | What is it that you want? |
22:14:38 | ldlework | stisa, when I use that I get Error: object constructor needs an object type |
22:14:57 | ldlework | dom96: just to initialize a non-ref type on a single line |
22:14:58 | FromGitter | <couven92> case 1: do somtheing then jump to case 2, case 2: do something else |
22:15:18 | ldlework | couven92, functions? |
22:15:34 | FromGitter | <couven92> ok... :P |
22:16:01 | ldlework | dom96: you know what I mean? |
22:16:24 | dom96 | You construct ref and non-ref objects in the same way |
22:16:29 | dom96 | Using the object constructor syntax |
22:16:42 | dom96 | Obj(field1: 51, field2: "asd") |
22:16:50 | ldlework | I'm telling you |
22:16:57 | ldlework | I'm getting the error when I do that |
22:17:04 | dom96 | Okay, what is your code? |
22:17:15 | ldlework | Region*[T: int|float] = object left*, top*, right*, bottom*: T |
22:17:22 | ldlework | root.region = Region(left:0, top:0, right:100, bottom:100) |
22:17:46 | dom96 | You need to tell it what 'T' is |
22:17:52 | FromGitter | <stisa> Idlework : did you try Regionint (...) ? |
22:17:53 | dom96 | Region[int](...) |
22:17:55 | ldlework | oh |
22:18:03 | ldlework | nice |
22:18:06 | ldlework | thank you |
22:18:17 | dom96 | And yeah, the errors could be much better. |
22:18:34 | ldlework | I really did try to think for myself, I just could not understand it. Thank you agian. |
22:18:38 | dom96 | Improving them should be a nice and easy way to get started with compiler development :) |
22:18:59 | dom96 | I can see why it wouldn't be obvious |
22:19:52 | dom96 | I could only guess what the error meant myself |
22:20:51 | ldlework | in hind sight it makes more sense |
22:21:00 | ldlework | if you take out the word "object" its clearer already |
22:21:04 | ldlework | constructor needs type |
22:21:04 | * | couven92 quit (Quit: Disconnecting) |
22:21:06 | ldlework | :) |
22:21:11 | ldlework | "Oh" |
22:21:18 | ldlework | but maybe that's hindsight |
22:21:33 | * | fvs left #nim ("leaving") |
22:22:24 | dom96 | "object constructor needs a generic type" would be better I think |
22:23:18 | dom96 | but there are probably scenarios where this same error is used and that wouldn't make sense :) |
22:26:20 | * | nsf joined #nim |
22:31:18 | * | bjz quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
22:31:43 | ldlework | Now I've got, https://gist.github.com/dustinlacewell/ce12a355f21be45e8fbfde6f0bca22d0 |
22:32:27 | ldlework | nm |
22:33:10 | dom96 | Be careful with this sort of code: self.width[T]() |
22:33:41 | dom96 | UFCS doesn't work in such a situation IIRC |
22:33:46 | dom96 | or in similar code |
22:33:56 | dom96 | so you need to write: width[T](self) sadly |
22:36:20 | ldlework | dom96: somehow underspecifying worked |
22:36:24 | ldlework | so just `width` |
22:36:41 | dom96 | yeah, sometimes the compiler can figure it out |
22:47:23 | * | rauss joined #nim |
22:57:23 | dom96 | huh, when did "hint" become green in the compiler's output? Didn't it used to be yellow/orange? |
22:57:41 | dom96 | or maybe i'm just dreaming |
23:01:05 | * | libman quit (Quit: Connection closed for inactivity) |
23:10:20 | * | yglukhov joined #nim |
23:15:20 | * | yglukhov quit (Ping timeout: 264 seconds) |
23:19:15 | * | Matthias247 quit (Read error: Connection reset by peer) |
23:40:38 | * | tax left #nim ("Leaving") |
23:48:43 | * | bjz joined #nim |
23:58:44 | ldlework | how to remove element from a seq |
23:58:50 | ldlework | really iterate it and use delete? |