<< 07-04-2017 >>

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:35FromGitter<Varriount> zachcarter: So what implementation did you end up using?
01:28:11zachcarterbasically just using spawn and keeping track of the flow vars
01:28:44FromGitter<Varriount> zachcarter: How hard was it to code?
01:28:55*rauss joined #nim
01:29:02zachcarterwasn’t too bad but I’m still dealing with certain asset types, like texture atlases
01:29:07FromGitter<Varriount> I know @Araq will be happy that you're using spawn
01:29:23zachcarterthey’re a pain in that they’re really a series of assets that need loading
01:29:30zachcarterbut spawn was easy to use
01:29:45zachcarterthe casts are a bit annoying
01:29:48zachcarterlike -
01:29:58zachcarterlet atlasInfo = cast[FlowVar[AtlasInfo]](assetLoadInProgress).`^`()
01:30:08zachcarterbut I’m sure I could write a macro or a template to make that not so bad
01:30:40FromGitter<Varriount> Why did you need the casts?
01:30:58FromGitter<Varriount> I mean, why weren't those variables flowvars to begin with?
01:31:56zachcarterI guess I could turn them into FlowVars, but I had written all those types before I started using them with spawn
01:32:03zachcarterand FlowVars have a type
01:32:11zachcarterassociated with them
01:34:18FromGitter<Varriount> Huh. I thought FlowVar types were generated from spawn. I didn't know you needed to define them separately.
01:36:16zachcarterI may very well be doing something incorrectly
01:37:35zachcarterI wish I could just do this with async / await
01:37:39zachcarterbut I really don’t have a strong grasp on it
01:37:58zachcarterI guess the procedure that does the loading of the file itself has to be asynchronous
01:38:18FromGitter<Varriount> zachcarter: async/await Is single-threaded.
01:38:28zachcarteroh
01:38:56FromGitter<Varriount> For asset loading you probably want a concurrent approach.
01:39:15zachcarterright
01:39:20zachcarterwhich is what I’m doing now I believe
01:39:50FromGitter<Varriount> https://nim-lang.org/docs/manual.html#parallel-spawn
01:40:45FromGitter<Varriount> So, for example, you might have an "AssetObject" type, with variants for holding different kinds of assets
01:41:13zachcarterpretty much exactly what I have
01:41:51FromGitter<Varriount> And then have a sequence `seq[FlowVar[AssetObject]]`
01:42:20zachcarterah okay
01:42:21zachcarterI just have
01:42:25zachcarterseq[AssetObject]
01:42:57FromGitter<Varriount> And you would use `spawn` to append results from an asset loading procedure into that sequence.
01:43:50zachcartermakes sense
01:44:24FromGitter<Varriount> Then you can use `^` to retrieve the value from the flowvar.
01:44:57FromGitter<Varriount> FlowVars are essentially like Promises or Futures - they hold a result that may not exist yet.
01:45:04zachcarterright
01:45:54FromGitter<Varriount> (I wish there was a proper, non-operator procedure to get the final result)
01:47:45FromGitter<Varriount> zachcarter: I'd be wary about casting to/from a flowvar. I'm surprised you're not getting data curruption
01:48:07FromGitter<Varriount> https://github.com/nim-lang/Nim/blob/master/lib/pure/concurrency/threadpool.nim#L99
01:48:23zachcarterhmm
01:49:08zachcarteryeah I’m going to fix this now
02:29:44ldleworkis this a good structure for a 2D BSP? https://gist.github.com/dustinlacewell/5bd54110f611b93f387a5f1aaf53558a
02:36:29FromGitter<Varriount> BSP = Binary Space Partitioning ?
02:38:38FromGitter<Varriount> ldlework: Wouldn't the "content" member of the "Leaf" variation be a sequence?
02:39:18ldleworkVarriount, it will just refer to some view object which will know how to draw some window
02:39:41ldleworknot sure why it would be a sequence
02:40:34*rauss quit (Quit: WeeChat 1.7)
02:41:36FromGitter<Varriount> ldlework: I was thinking nodes in a scenegraph
02:41:50*rauss joined #nim
02:44:49ldleworkVarriount think tiling window manager
02:45:48*yglukhov joined #nim
02:50:11*yglukhov quit (Ping timeout: 260 seconds)
03:05:25zachcarterhttp://imgur.com/a/xEvYQ
03:09:40FromGitter<Varriount> zachcarter: \o/
03:09:52zachcarter:D
03:11:14FromGitter<Varriount> zachcarter: Did you do the graphics?
03:11:32zachcarternope!
03:11:34zachcarterthey’re kenny's
03:11:49zachcarterhttps://kenney.nl/assets
03:16:34ldleworkhow do I default parameter as nil/
03:16:42ldleworkhow do I set the type and specify the default at the same time
03:17:11FromGitter<Varriount> ldlework: Yes.
03:18:02ldleworkwhat?
03:18:47FromGitter<Varriount> ldlework: `proc foo(parameter: ref Bar = nil)`
03:19:57ldleworkthansk
03:24:01ldleworkVarriount, this look right? https://gist.github.com/dustinlacewell/a72f967694ca8920e022611877b6c171
03:24:34ldleworkoh hmm no
03:25:17ldleworkhttps://gist.github.com/dustinlacewell/a72f967694ca8920e022611877b6c171 there we go
03:31:00ldleworkhow do you tell if something is nil without crashing
03:31:09FromGitter<Varriount> isNil()
03:32:50ldleworkoops "var result"
03:32:52ldleworkouch
03:32:53ldleworkhard to spot
03:34:20ldleworknice
03:34:45*winnebagel joined #nim
03:36:03*[ui] joined #nim
03:46:28ldleworkhow does default equality work
03:49:40ldleworkVarriount, if I remove the return statement here the test fails, https://gist.github.com/dustinlacewell/5ecf21397e3bbce3e1af7fda49d2e9d9
03:49:47ldleworkline 66
03:53:21ldleworkdoes 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:51ldleworkis there a better way to do, compiles((Leaf[string])root)
04:52:26*yglukhov quit (Ping timeout: 260 seconds)
04:56:25ldleworkWhy doesn't this work? https://gist.github.com/dustinlacewell/357da4321c041ff69d0503d6994b23af
04:56:33ldleworksomeoneeeeeee
04:57:58ldleworkhmm
04:58:18ldleworkdoing compiles((any type at all)root) seems to be true
04:58:21ldleworkwtf
05:01:06ldleworkhmm interesting can't upcast...
05:01:42ldleworkIf you have an A B subtype relation
05:01:46ldleworkand you have some type that stores A
05:01:49ldleworkand you pass it a B
05:01:59ldleworkand then somewhere else get the value back
05:02:05ldleworkis there a way to use it as a B again?
05:02:21ldleworkI feel like this is a pattern I suffer with chronically :D
05:03:07*ldlework scratches head
05:04:06ldleworkyou all just love to watch me squirm ;)
05:06:44ldleworkI see, somehow `of` magically knows
05:09:52ldleworknice
05:39:53*winnebagel left #nim ("ii - 500 SLOC are too much")
05:41:37*sz0 joined #nim
05:54:06ldleworkman you can really compact code with inheritance
05:54:35ldleworkHoly Refactoring Batman!
06:00:36FromGitter<Varriount> ldlework: Sorry, what?
06:01:05FromGitter<Varriount> Were you not using inheritance before?
06:07:57*Vladar joined #nim
06:12:56ldleworkVarriount how can I make this better, https://gist.github.com/dustinlacewell/d9a748b7bcc5e85094e84377da825a43
06:13:09ldleworkthe implementations are exactly the same
06:13:16*babs_ quit (Quit: Leaving)
06:14:01ldleworkoh it doesn't even work
06:14:32ldleworkVarriount, read above about my problem regarding AB subtype relations
06:14:35ldleworkand up-casting
06:14:39ldleworkplease
06:17:24*[ui] quit (Quit: Connection closed for inactivity)
06:19:48ldleworkoh duh
06:19:51ldleworkadd another generic arg
06:22:25*nsf joined #nim
06:27:50ldleworknoice
06:33:15*brson quit (Ping timeout: 260 seconds)
06:44:30FromGitter<Varriount> ldlework: I think I need to see more of the code first
06:45:51FromGitter<Varriount> Inheritance and generics don't work too well together.
06:47:00FromGitter<Varriount> Normally I'd suggest you use methods, but I don't know if they work with generics
06:47:26euantorRust might have Nim beat, getting mentioned in batgirl: https://twitter.com/chasinglogic/status/850115493923086336
07:04:04*rokups joined #nim
07:05:15ldleworkVarriount: https://gist.github.com/dustinlacewell/8d6bec431ed977976bb40915c5428a52 \p/
07:07:03ldleworkThere's a lot of casting in this version
07:07:56ldleworknow 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:05Araqeuantor: 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:23euantorAraq: :)
07:49:19Araqhttps://www.youtube.com/watch?v=QELRiIeJY1U
07:51:38ldleworkhehe
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:13ldleworkhttp://i.imgur.com/DxkEKhT.png my BSP is working
08:39:20*cspar quit (Ping timeout: 264 seconds)
09:15:34FromGitter<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:19subsetparkldlework: what WM is that?
09:29:59*Andris_zbx joined #nim
09:31:53ldleworksubsetpark: its not a vm, its just a bsp I'm writing in nim
09:31:58ldleworkunless you mean my actual vm, then qtile
09:32:26subsetparkyeah, 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:37couven92Araq, 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:22Araqcouven92: can't work
10:35:41Araqnim is not homoiconic enough for this
10:35:50Araqbut you can use a macro
10:36:35couven92ok... parsing the AST... right, after learning template, now I have do more reading... Thanks Araq! :)
10:37:20couven92PMunch, told how excited he was after doing that wxnim macro... so I'm looking forward to it! :D
10:40:58couven92can 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:42PMunchcouven92, if you look at the wxnim macro it does that
10:44:51couven92ok thx
10:55:57arnetheduckAraq, https://github.com/nim-lang/Nim/pull/5656?
10:56:21Araqarnetheduck: will merge it later ok?
10:56:39arnetheduckgreat, thanks.. mainly wanted to know if it'll go in
10:57:04arnetheduckhave some other stuff that depends on it, sort of
10:58:31AraqI've a growing collection of nimble package tests that are becoming another acceptance criterion before PRs can be merged
10:59:02AraqI hope I can update travis this weekend to check for more things
11:06:29arnetheduckhope those things run in parallel then, because the tests are taking quite long as-is
11:07:00arnetheduckbut good development nonetheless
11:07:43arnetheduckosx is missing from the automated runs, no?
11:09:21Araqthey are run on osx but travis' osx runner has a bug
11:09:33Araqit reports "failure" even though everything is green.
11:09:51Araqso we need to look at it with our own eyes :-(
11:10:46AraqI think travis' whole architecture is a bunch of horrible bash scripts :-)
11:12:33euantorSo just bash scripts then, I've yet to see a "nice" bash script :P
11:13:27Araqwell there is still the distinction between "working and horrible" and "broken and horrible" :P
11:14:31Araqand then there is the usual "working as long as your filenames have no space and horrible" bash script
11:16:23arnetheduckwhitespaceisoverratedanyway
11:37:53FromGitter<Danielez> Hello is there a tool to translate python to nim? or even a first approximation of this to then work on?
11:41:33FromGitter<TiberiumPY> not yet :)
11:41:42FromGitter<TiberiumPY> but it's not hard to translate simple python
11:41:47FromGitter<TiberiumPY> without any dynamic features
11:41:48FromGitter<andreaferretti> a first approximatino is often just copying the source :-)
11:41:52FromGitter<TiberiumPY> yeah
11:42:05FromGitter<andreaferretti> and then adding types
11:42:09FromGitter<TiberiumPY> I did that for a few times when I need to translate simple python script :D
11:44:39FromGitter<Danielez> Ok, thanks
11:45:06FromGitter<TiberiumPY> but yeah, maybe in the future we'll see this tool like pas2nim, but py2nim
11:45:43FromGitter<TiberiumPY> @Danielez but translating big python frameworks/programs is not easy
11:45:57FromGitter<TiberiumPY> because there's almost 100% chance they contain a lot of dynamic features
11:46:22FromGitter<TiberiumPY> (btw, overloading in Nim looks better for me than using isistance() in Python)
11:46:28Araqhttps://forum.nim-lang.org/t/2705#16724
11:46:52Araqit can be used to translate Python to Nim, I hope
11:49:37FromGitter<TiberiumPY> oh, there's "auto" in nim?
11:49:49FromGitter<TiberiumPY> I didn't know about it :D
11:50:41*BitPuffin|osx joined #nim
11:51:44FromGitter<Danielez> Thank you @Araq and @TiberiumPY
11:55:16FromGitter<TiberiumPY> @Araq so you can use ```auto``` to get inferred types after first compilation (if you translate from python)?
11:58:11FromGitter<TiberiumPY> or even if you're lazy :D
12:00:36couven92Ok, I have now created a macro as Araq suggested: https://pastebin.com/ggtYWkb4
12:00:41couven92Now when I compile I get: https://pastebin.com/ggtYWkb4
12:00:50couven92sry, SIGSEGV: Illegal storage access. (Attempt to read from nil?)
12:01:19couven92what am I doing wrong now... How can I debug my macro?
12:03:57couven92https://pastebin.com/P5a2qtNu (added what I expect the macro to produce)
12:04:09FromGitter<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:48FromGitter<evacchi> (I understand discussions about syntax are mostly sterile but I'm genuinely interested)
12:07:46*zachcarter quit (Quit: zachcarter)
12:12:39Araqevacchi: initially pragmas only existed for procs and here the syntax is nice enough. and then they were patched into other places
12:13:14Araqalso it wasn't obvious back then they would become heavily used -.-
12:16:54FromGitter<evacchi> :P
12:17:37FromGitter<evacchi> @araq: wouldn't they "scan" better if they were prefix ?
12:17:46*PMunch quit (Ping timeout: 240 seconds)
12:17:52FromGitter<evacchi> I think it might make the language more "regular"
12:18:01FromGitter<evacchi> there's quite a few places where they already are prefix
12:18:57FromGitter<evacchi> like, you know: `@thread proc foo()` or `[thread] proc foo() ` (*cough cough* annotations *cough*)
12:19:12FromGitter<Varriount> @evacchi I've suggested that to. It would certainly make pragma-heavy procedures more readable...
12:19:26FromGitter<Varriount> *too
12:19:27FromGitter<evacchi> would love that
12:19:45FromGitter<evacchi> but you know, I understand this would not be high on a priority list
12:28:11FromGitter<Varriount> @evacchi Right now there would be syntactic ambiguity.
12:29:04FromGitter<Varriount> Take for example `{.experimental.}`, which is a standalone pragma used to enable experimental features in a module
12:29:40FromGitter<Varriount> What would happen if that pragma was placed right before a procedure?
12:31:04FromGitter<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:14Araqhuh? I can see {..} are not exactly sexy, but prefix syntax? seriously?
12:33:30*shashlick quit (Ping timeout: 260 seconds)
12:33:37Araq@random @crap @Idontcareabout proc finallyTheNameHere()
12:33:55Araqimportant stuff should come first, not last. :P
12:34:13FromGitter<Varriount> @araq between effects, locks, and macros, a procedures pragma section can get really big
12:34:16*shashlick joined #nim
12:34:31Araqvarriount: the docgen folds it fwiw
12:34:59FromGitter<Varriount> That's great. Text editors don't.
12:35:08Araqthey could :P
12:35:32Araqand since you're the author of the sublime plugin, you know what you've got to do now ;-)
12:35:51FromGitter<Varriount> And github? Paste sites?
12:36:33FromGitter<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:05AraqI planned to take over NimLime but I don't exactly have much time either
12:37:51Araqso 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:16Araqalso, effects are inferred, so the issue is more severe for the generated docs
12:38:28Araqwhich do fold already.
12:38:43FromGitter<Varriount> It just makes a procedure ugly when the pragma section crosses more than one line
12:39:11FromGitter<Varriount> Besides, users shouldn't have to rely on editors to cover up a languages warts.
12:39:34Araqit's not a "wart".
12:39:43Araqit's a personal dislike by some people.
12:40:03Araqand you seem to be more concerned about the placement of the '=' afaict
12:40:06Araqproc foo() =
12:40:15Araq {.raises: [], ....}
12:40:27Araq echo "would be an improvement?"
12:40:57FromGitter<Varriount> Possibly.
12:41:35couven92Araq, 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:08Araqcouven92: please file a github issue. debugging a macro is usally done by 'echo repr result'
12:42:24couven92ok, thx
12:42:33Araqbut not if the fucking compiler crashes :-(
12:43:31PMunchcouven92, any idea where the SIGSEGV occurs?
12:43:42couven92nope
12:43:51PMunchAnd for any syntax stuff you should really look at dumpTree
12:44:04couven92ah ok... will try
12:44:09PMunchSo dumpTree whatever you want to create and then look at what that gives you :)
12:44:47PMunchBut 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:24FromGitter<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:28PMunchcouven92, it's not the empty add statement on line 8 which causes it?
12:45:43FromGitter<evacchi> like `private something something void foo()`
12:45:46couven92oh
12:45:56couven92PMunch, that might be... let's see
12:47:01FromGitter<evacchi> besides, since it comes after the `):` looks a bit like its something pertaining to the return value
12:47:15Araqevacchi: yeah, I don't like it. I never got used to C based syntax really, even after years. it's ugly.
12:47:29Araqand backwards.
12:50:18couven92Araq, 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:58FromGitter<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:02PMunchDoesn't do what? Doesn't show the *?
12:51:18FromGitter<evacchi> modifiers such as thread, and gcsafe change quite a bit the contexts where the proc can be used
12:51:24PMunchThe error really shouldn't end in a SIGSEGV though so you should still create an issue :)
12:51:29FromGitter<evacchi> so you *should* care about those
12:53:54*zachcarter joined #nim
12:54:29PMunchAraq, I like the idea of putting pragmas after the = makes it easier to read at least, if not a bit confusing semantically.
12:57:06FromGitter<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:58FromGitter<evacchi> i mean: `proc foo() = {.blah.}` `proc bar(f : proc(){.blah.})` <-- no `=` here!
12:58:10PMunchYeah
12:58:16PMunchSame for forward declaration of procs
12:58:30PMunchWhere you don't have a =
12:58:39PMunchThat would be a bit confusing
12:58:42FromGitter<evacchi> yes
12:59:35couven92PMunch, 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:52FromGitter<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:05FromGitter<evacchi> :P
13:00:14FromGitter<Varriount> I just want something that makes it more likely `proc ` and `=` are on the same line
13:00:33PMunchOh wait, were you trying to do it in the name part when defining the function?
13:00:47PMunchThat would make it "proc `myFunc*`()"
13:01:06PMunchSo the name would be myFunc* and now be an exposed procedure
13:01:45FromGitter<TiberiumPY> @evacchi i like this style, it's like decorators in python
13:02:09FromGitter<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:22FromGitter<evacchi> and it would probably work for type declarations as well like `type @bar Foo`
13:07:17FromGitter<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:24FromGitter<evacchi> anyway, just my 2c
13:43:00*smt quit (Read error: Connection reset by peer)
13:47:07couven92ok, 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:33couven92or maybe I should reparse the reclist argument as a nnkRecList node?
13:50:14PMunchJust write a loop that creates a RecList from the StmtList
13:50:25PMunchfor r in stmtlist:
13:50:51PMunch reclist.add(Record(r[0],r[1][0]))
13:50:56PMunchOr something like that
13:51:42PMunchThat's just pseudo-code by the way
13:52:46couven92PMunch, the object parameters list can be very complex: https://nim-lang.org/docs/macros.html#statements-type-section
13:53:32PMunchAh..
13:53:44PMunchAnd you can't just add it untyped?
13:54:01*smt joined #nim
13:55:45couven92Well 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:44couven92Araq, how do I call another macro inside a macro?
14:43:13Araqyou ... call it?
14:43:31Araqjust like you would call a .compileTime proc
14:44:03couven92doesn't work... it says that the arguments don't match, expected string but got NimNode
14:44:21Araq getAst m(...)
14:44:41FromGitter<andreaferretti> I think maybe you don't want to call it, but generate a call to it
14:44:48FromGitter<andreaferretti> which will eventually be compiled again
14:45:06Araqthat's possible, or u use getAst
14:46:03Araqwhich works by chance but since I'm aware of it, it will make it into the spec
14:46:53AraqI would extract the common logic in a .compileTime proc that is used by both macros
14:48:20Araqandreaferretti: .immediate templates and macros all have untyped parameters, the types are lies
14:48:42Araqso if it works today with .immediate, it should also work with all parameters 'untyped'
14:48:54FromGitter<andreaferretti> this is quite bizarre
14:49:02FromGitter<andreaferretti> so the use case is the following
14:49:14Araqwell .immediate is deprecated for a reason.
14:49:15FromGitter<andreaferretti> you have an expression and you want to do pattern matching on it
14:49:31FromGitter<andreaferretti> so you need to know the type of the expression
14:49:48FromGitter<andreaferretti> because, say, you want to know how the fields are called
14:50:00FromGitter<andreaferretti> or what are the possibilities in a variant type
14:50:13FromGitter<andreaferretti> on the other hand, the body of the pattern matching will be untyped
14:50:29FromGitter<andreaferretti> because, well, it is not well formed in the first place
14:50:39FromGitter<andreaferretti> and our task is exactly to rewrite it
14:51:02FromGitter<andreaferretti> so I am not sure how I can use an untyped parameter for the expression
14:52:01FromGitter<andreaferretti> uh sorry, I am talking about the `match` macro
14:52:12Araqmacro match(pattern: typed; body: untyped)
14:52:13FromGitter<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:02FromGitter<andreaferretti> that one does not need the type on `e`
14:53:09FromGitter<andreaferretti> turns out it works fine this way
14:53:14FromGitter<andreaferretti> great! :-)
14:53:22FromGitter<andreaferretti> I can remove immediate
14:54:26Araqyeah, the language is much better without .immediate
14:54:46Araqand there are no known cases where the workaround wasn't easy.
14:54:53FromGitter<andreaferretti> I don'think I was using it elsewhere
14:57:17*bjz joined #nim
15:03:15*couven92 quit (Quit: Disconnecting)
15:05:46FromGitter<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:53FromGitter<andreaferretti> try to write that and use https://nim-lang.org/docs/macros.html#dumpTree.m,untyped to see the generated tree
15:08:00FromGitter<andreaferretti> and compare that one with yours
15:08:16FromGitter<andreaferretti> maybe you are missing some node that is not shown in the source
15:08:23FromGitter<couven92> @andreaferretti ok, will try
15:08:30FromGitter<andreaferretti> such as statement sequence or such
15:09:00cheatfatennkEmpty nodes is also important, dont try to miss it
15:11:34FromGitter<couven92> Uhm, how do I dump the results of the macro?
15:11:51def-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:18FromGitter<couven92> def-, that gives me the source the macro produces, not the AST tree dump
15:13:33FromGitter<andreaferretti> echo result.treeRepr
15:13:39FromGitter<couven92> ah
15:14:40FromGitter<couven92> ok, the whenStmt needs to be in a StmtList... make sense
15:14:56*vlad1777d joined #nim
15:21:29zachcarterdoesn’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:12Araqit does, so use a path to disambiguate
15:23:18*Varriount|Mobile joined #nim
15:23:34Araq import oprypin / random or something
15:23:54zachcarterah okay
15:23:55Araqor import random / random
15:29:01*Vladar joined #nim
15:35:32zachcarternot sure how to do that with a nimble dependency
15:35:35zachcarterneither 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:15dom96IIRC disambiguating between stdlib and nimble packages is still not possible in certain cases. There is a bug for this on GitHub
15:52:02zachcarterah okay
15:52:16FromGitter<couven92> Could we prefix nimble packages with nimble /
15:52:37FromGitter<couven92> Since the compiler has to be nimble aware anyways?
15:53:14FromGitter<couven92> Breaking change though... :/
15:53:42dom96Here is the relevant issue https://github.com/nim-lang/Nim/issues/2819
15:55:18demi-packages should be namespaced
15:55:36*bjz joined #nim
15:55:45demi-it is really up to the third party devs to not pick package names that don't conflict with the stdlib
15:56:57dom96The random package was introduced before the 'random' module was added to the stdlib.
15:57:12FromGitter<couven92> demi- what about multiple package authors?
15:57:27dom96The standard library will evolve, who knows what modules will be in it in 2 years
15:57:46dom96People may have private packages that we are not aware of that will conflict with it.
15:57:50demi-i believe python solves this by having syntax for `import foo as bar`
15:58:07dom96So it's not even just a case of making sure the new stdlib modules don't conflict with public packages.
15:58:38dom96Doesn't that only rename the import?
15:59:04dom96'foo' could still be in the importing module's directory, in a package or in the stdlib.
15:59:41demi-couven92, not sure i follow what you mean
16:00:22demi-dom96: ¯\_(ツ)_/¯ most ecosystems i know of follow the pattern of "third party devs will have to deal with it"
16:00:38dom96lol
16:00:43dom96we could take this stance too
16:01:01dom96But I don't think it's a good idea
16:01:16demi-yeah it isn't great, it is just the most common approach i've seen
16:01:39dom96It would be nice if the `random` package was renamed as a good-enough short-term fix though.
16:02:53demi-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:20demi-that is viable since we are using a centralized package repo
16:03:28dom96I'm not sure how that would help
16:04:09demi-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:11dom96You mean Nimble should verify it when installing packages?
16:04:58dom96For the packages repo I could add that sure, but it wouldn't help with future additions to the stdlib
16:05:32demi-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:18demi-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:25dom96It would be helpful, but it wouldn't have helped prevent the situation with the 'random' package.
16:13:41demi-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:29dom96Indeed, 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:15dom96Not sure if Travis or my fault https://travis-ci.org/nim-lang/nimble/builds/219753897#L675
16:55:19dom96But WTF
16:55:52dom96bah, I thought it would create a new build if I restart it.
16:56:03dom96In any case, it gave a "Out of memory" error.
17:00:42PMunchSeems to be chugging along fine so far
17:02:06*Matthias247 joined #nim
17:03:47demi-dom96: i'm still seeing high memory usage with jester
17:04:23*yglukhov joined #nim
17:04:30dom96even with mark and sweep and/or boehm?
17:05:17demi-mark and sweep
17:06:34dom96That sucks, any chance you could reproduce the leak?
17:06:52demi-how do you mean?
17:08:56dom96Come up with something I can run to reproduce the high memory usage?
17:10:04demi-well the code is pretty simple, since it is only doing static file hosting; wouldn't that indicate this is traffic related?
17:12:56dom96Well... it seems to happen slowly
17:13:14dom96So figuring out what the problem is won't be easy
17:13:24dom96I'm wondering if there is any way to speed up the process
17:17:46dom96You can also try using jester's devel branch, it handles static files a little bit differently.
17:18:27dom96But 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:30dom96unmarshalling an object variant sure is fun
18:46:25*fvs joined #nim
18:46:45fvshi, is it possible to convert a seq to an array?
18:48:37dom96hello, why do you wish to do that?
18:53:08*BitPuffin|osx quit (Ping timeout: 264 seconds)
18:54:01fvsdom96, to pass as parameter to dll
18:54:27dom96fvs: addr seq[0]
18:54:31dom96Is what you want I think.
18:58:25cheatfatefvs, addr(sequence[0])
18:58:42cheatfatebut GC_ref() it before
18:58:50cheatfateor even better use system.protect()
19:17:27Arrrrprotect? is that new?
19:17:30fvsthanks, I need to pass it as a ptr, so I guess > var aptr: ptr T = cast[ptr T](seq[0].addr)
19:19:35cheatfateArrrr, 0.14+ i think
19:20:40dom96fvs: You don't need the cast
19:21:14dom96or at least you shouldn't need it if your DLL is wrapped well.
19:33:18*Arrrr quit (Quit: Leaving.)
19:40:08fvscheatfate, to confirm first protect and later "dispose" to GC?
19:40:26cheatfatefvs, yeah
19:43:38*Varriount|Mobile quit (Read error: Connection reset by peer)
19:43:44*Varriount|Phone joined #nim
19:53:24FromGitter<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:55ldleworkcan 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:11fvsto convert what?
20:30:38fvscelsius to fahreheit?
20:37:17*tinAndi joined #nim
20:39:19*yglukhov quit (Remote host closed the connection)
20:42:16ldleworkError: identifier expected, but found 'texture.info.size.w' ??
20:42:25ldleworkwhat does this mean?
20:42:39ldlework 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:11ldleworktype Point2D[T: int|float]* = object
21:01:14ldlework x, y: T
21:01:23ldlework Error: implementation of 'Point2D' expected
21:01:25ldleworkWhat does this mean
21:03:35FromGitter<Varriount> On what line is the compiler throwing that error?
21:04:27ldleworkthe first
21:04:51ldleworkah its the *
21:05:07ldleworkbad 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:31ldleworkare basic non-ref objects covered anywhere?
21:21:56ldleworkhow do I create an instance of a `type Foo = object ..` ?
21:22:33dom96Foo()
21:24:07ldleworkno
21:24:23ldleworkError: object constructor needs an object type
21:24:35FromGitter<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:15FromGitter<Varriount> `var x: Foo`, `x.bar`
21:25:35ldleworkattempting to call undeclared routine: 'left='
21:26:54FromGitter<Varriount> ldlework: Could you just show us all your code?
21:27:41ldleworkhttps://gist.github.com/dustinlacewell/16551703767efd32411c6782f79016be
21:29:28FromGitter<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:54dom96couven92: hehe, great :)
21:30:14dom96I'm writing a macro to deserialize JSON into a type.
21:30:26dom96Not as easy as I thought it would be
21:30:32FromGitter<Varriount> ldlework: https://glot.io/snippets/eoq7v62lqn
21:30:51FromGitter<Varriount> dom96: Might want to take a look at NimYAML
21:31:05ldleworkVarriount sure but what's my problem?
21:31:49dom96Varriount: Doesn't it work the same way as the marshal module?
21:34:14*Vladar quit (Quit: Leaving)
21:34:55ldleworkI'm so confused
21:36:42dom96ldlework: export the fields, maybe?
21:37:01ldleworkError: illformed AST: utils.Region[]
21:37:06ldleworkO_O
21:37:46FromGitter<Varriount> ldlework: *All* of your code?
21:37:59ldleworkdom96: you are the winner
21:38:20ldleworkbut thank you Varriount
21:38:58ldleworkI wonder if the compiler could know that the field of that name exists but isn't exported
21:39:02ldleworkand offer the advice
21:40:54*onionhammer quit (Read error: Connection reset by peer)
21:41:15*onionhammer joined #nim
21:50:56ldleworkmain.nim(124, 18) Error: invalid type: 'T' in this context: 'proc (app: App): GameScene'
21:51:23ldleworkfunction isn't even generic
21:55:05ldleworkVarriount, 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:04ldleworkI don't know what this error means
21:59:25ldleworkugh
22:02:09ldleworkohh
22:04:02dom96types are generic?
22:08:34ldleworkback in action!
22:09:34ldleworkits too bad there is no easy way to create a new non-ref on a single line
22:09:39ldleworkIE, struct literals..
22:09:51*yglukhov quit (Remote host closed the connection)
22:10:12dom96there is if you define both
22:10:22ldlework?
22:10:28dom96type FooObj = object; FooRef = ref FooObj
22:10:51ldleworkand then?
22:11:54dom96FooObj()?
22:12:08ldleworkI don't get it, why is it required to define FooRef?
22:12:48FromGitter<stisa> Idlework: are you looking for something like https://nim-lang.org/docs/manual.html#types-object-construction ?
22:13:02FromGitter<couven92> uhm, goto another case in Nim? Possible? How?
22:13:41dom96ldlework: I dunno, my assumptions are probably wrong.
22:13:44dom96What is it that you want?
22:14:38ldleworkstisa, when I use that I get Error: object constructor needs an object type
22:14:57ldleworkdom96: just to initialize a non-ref type on a single line
22:14:58FromGitter<couven92> case 1: do somtheing then jump to case 2, case 2: do something else
22:15:18ldleworkcouven92, functions?
22:15:34FromGitter<couven92> ok... :P
22:16:01ldleworkdom96: you know what I mean?
22:16:24dom96You construct ref and non-ref objects in the same way
22:16:29dom96Using the object constructor syntax
22:16:42dom96Obj(field1: 51, field2: "asd")
22:16:50ldleworkI'm telling you
22:16:57ldleworkI'm getting the error when I do that
22:17:04dom96Okay, what is your code?
22:17:15ldlework Region*[T: int|float] = object left*, top*, right*, bottom*: T
22:17:22ldlework root.region = Region(left:0, top:0, right:100, bottom:100)
22:17:46dom96You need to tell it what 'T' is
22:17:52FromGitter<stisa> Idlework : did you try Regionint (...) ?
22:17:53dom96Region[int](...)
22:17:55ldleworkoh
22:18:03ldleworknice
22:18:06ldleworkthank you
22:18:17dom96And yeah, the errors could be much better.
22:18:34ldleworkI really did try to think for myself, I just could not understand it. Thank you agian.
22:18:38dom96Improving them should be a nice and easy way to get started with compiler development :)
22:18:59dom96I can see why it wouldn't be obvious
22:19:52dom96I could only guess what the error meant myself
22:20:51ldleworkin hind sight it makes more sense
22:21:00ldleworkif you take out the word "object" its clearer already
22:21:04ldleworkconstructor needs type
22:21:04*couven92 quit (Quit: Disconnecting)
22:21:06ldlework:)
22:21:11ldlework"Oh"
22:21:18ldleworkbut maybe that's hindsight
22:21:33*fvs left #nim ("leaving")
22:22:24dom96"object constructor needs a generic type" would be better I think
22:23:18dom96but 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:43ldleworkNow I've got, https://gist.github.com/dustinlacewell/ce12a355f21be45e8fbfde6f0bca22d0
22:32:27ldleworknm
22:33:10dom96Be careful with this sort of code: self.width[T]()
22:33:41dom96UFCS doesn't work in such a situation IIRC
22:33:46dom96or in similar code
22:33:56dom96so you need to write: width[T](self) sadly
22:36:20ldleworkdom96: somehow underspecifying worked
22:36:24ldleworkso just `width`
22:36:41dom96yeah, sometimes the compiler can figure it out
22:47:23*rauss joined #nim
22:57:23dom96huh, when did "hint" become green in the compiler's output? Didn't it used to be yellow/orange?
22:57:41dom96or 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:44ldleworkhow to remove element from a seq
23:58:50ldleworkreally iterate it and use delete?