<< 22-11-2013 >>
00:02:59Araqgood night
00:03:07VarriountGood night.
00:03:12MFlamernow I need to decide on some reasonable construction syntax like " x = Just(69)"
00:03:35VarriountMFlamer, what does "Just" mean?
00:04:14MFlamerwell its an enum variant, but in this case also sort of like a type constructor
00:04:29VarriountNo, I mean, the intended meaning of the name.
00:04:53MFlamerback to haskell convention for Maybe type
00:05:10MFlamercalled "Some" in Scala I think
00:05:30VarriountYou might want to think of a better name, because it isn't very obvious.
00:05:46VarriountI though it might be some concept of justification.
00:05:50Varriount*thought
00:07:07MFlamerwell, the user can create whatever types he wants. But, Maybe is a common sum type, so we would probably include in the lib. "Maybe" a better name would be good
00:07:36MFlamergood night Araq
00:08:51yogini'm new to nimrod, but i'm considering is it suitable for numeric & scientific computation
00:09:12yoginbasically, first-class arrays and matrices
00:09:22yoginand operator overloading
00:09:27Varriountyogin, how large are the number's you're going to be calculating?
00:10:26yoginu mean size of the arrays?
00:10:52VarriountNo, I mean, the size of the actual number you're going to be manipulating.
00:11:00Varriount*numbers
00:11:02yoginthe numbers themselves can be anything that double-precision supports
00:11:14yogini thing somewhere 1+e308
00:13:55yogincan I do x = y + z where y and z are both arrays?
00:14:19yoginlike in Matlab, Numpy, etc.
00:15:40VarriountI don't know. If you can't, you can always just define the operators.
00:16:14yoginok
00:16:32filwityogin: yes you can do all that
00:18:11yoginfilwit: is is possible with default Nimrod installation or should i use an external library (if such a thing exists at all) ?
00:18:21filwityogin: there is a basic Matrix (in the pure/basic32 module), or you can write your own. And operator-overloading in Nimrod is the same as regular functions :)
00:18:53filwityogin: for arrays, do: var myArray: array[0 .. 10, int]
00:19:00yoginah ok, i'll check it out, thanks
00:19:13filwitnp
00:19:45filwityogin: note: the basic3d module is, as far as i know, still new and not fully complete.
00:19:59filwityogin: but i'm not the author, so I don't know everything about it.
00:20:07Varriountyogin, if your feeling adventurous, you could come up with a bignum implementation. :p
00:21:14yoginoh well why re-invent the wheel? Can I not just link GMP with Nimrod?
00:21:43VarriountI suppose. Is there a wrapper?
00:21:49filwitif it's C/C++ you can
00:22:15yoginyea, it is pure C http://gmplib.org/
00:22:29filwityogin: yeah just googled it. it's fully possible
00:22:31Varriountyogin, how many macros does it use for the public api?
00:22:37yoginProbably we have to write a wrapper for that :)
00:22:46filwityogin: Nimrod works great with pure C (and visa versa, since Nimrod compiles to C)
00:23:25filwityogin: just wrap what you need in GMP to get your work done (forcus on a real wrapper later, if you really need it)
00:23:29Varriountyogin, we have a tool - c2nim - to help make wrapper. The only problem is that it doesn't like heavy, nonstandard macro usage.
00:25:03yogini see
00:25:22filwityogin: http://nimrod-lang.org/manual.html#foreign-function-interface
00:25:35filwityogin: that's info on how to talk to C
00:26:19yoginok
00:26:40yogini took a look at gmp.h and it's full of #define-s
00:27:08yoginthat is the only header file we need
00:27:22Varriountyogin, what about includes?
00:28:15yoginno, id doesn't #include anything at all
00:28:17C0C0what does "inheritance only works with non-final objects" mean?
00:28:20yogin*it
00:29:07Varriountyogin, then it should be quite easy - just feed the include file to c2nim (oddly enough, I can't find the main header file, gmp.h, in my download)
00:29:39VarriountC0C0, it means that objects that don't explicitly inherit from TObject are final, and cannot be inherited from.
00:29:58C0C0aah
00:30:25C0C0you might want to fix the samples in the manual then
00:30:55filwitC0C0: the documentation is something we're looking into fixing up relatively soon :)
00:31:14C0C0:)
00:31:15yoginVarriount: gmp.h is generated from gmp.h.in while compiling
00:31:22VarriountC0C0, the documentation is *really* out of date, unfortunately.
00:31:30Varriountyogin, ah, ok.
00:31:49Varriountyogin, if you have any problems with c2nim or the include file, I can help.
00:32:12yoginyea, i will try during weekend likely, don;t have time now
00:33:12filwityogin: one common gotcha in Nimrod when interfacing to C is that 'float' is 64bit by default (use float32 otherwise).
00:33:19fowlC0C0, you dont have to descend the object type from TObject, you can also mark it {.inheritable.}
00:33:36filwityogin: but there is also 'cfloat', which will match C standards
00:33:44yoginfilwit: a thanks for pointing out
00:33:44filwityogin: just a heads-up
00:33:48C0C0fowl: cool thx :)
00:34:53filwitC0C0: you can explicitly mark an object as {.final.} too, to stop inheritance.
00:35:11C0C0I really like the idea with the annotations
00:35:14yoginVarriount: where can i download c2nim?
00:35:33fowlfilwit, you dont need to
00:35:42filwitfowl: i know
00:35:49fowlooooo >:)
00:35:59filwit:)
00:36:00Varriountyogin, it's generated when you build the compiler, I think.
00:36:08fowlmaybe type TFoo = object of TObject {.final.} would work
00:37:11filwitfowl: well.. i was just mentioning {.final.} because it was relevant to inheritance.
00:37:37yoginVarriount: found it, was in ./compiler/c2nim
00:50:28yoginI just tried c2nim on gmp.h, it failed with some error:
00:50:37yogingmp.h(217, 31) Error: ';' expected
00:50:54yoginThe file gmp.h is here: https://gist.github.com/anonymous/7592761
00:52:14Varriountyogin, any reason that line has what appears to be 3 arguments?
00:53:19yogini think it is something like typedef "struct abc*" xyz; so valid
00:53:48yoginok, it's just const :P
00:53:55VarriountAh, I think I see.
00:54:19VarriountTry eliminating the use of gmp const
00:54:26VarriountEr, __gmp_const
00:58:42Varriountyogin, I'll look at the file, and see if I can translate it.
00:58:56yoginok, thanks!
00:59:11Varriountc2nim isn't perfect, and most files need some degree of editing before it'll accept them.
00:59:22yogini just replaced __gmp_const --> const but the error persists
00:59:33Varriountyogin, you just delete it.
00:59:52VarriountNimrod tries to convert typedefs to actual types
01:00:19Varriount*c2nim
01:00:21Varriountor something along those line
01:00:54yogindoesnt nimrod have a 'const' keyword?
01:01:10yoginsomething that says "immutable?
01:01:13Varriountyogin, yes, but not in the same way c++ and c does
01:01:44Varriountyou can use 'let' as a constant version of 'var', and 'const' for some global stuff I think.
01:02:19EXetoCconst for compile-time constants
01:02:28Varriount^
01:02:36yoginaye aye
01:02:50EXetoCwhy is there a distinction between `/` and `div`? it doesn't exactly help when it comes to writing generic code
01:03:22Varriountyogin, also, it doesn't like anonymous structs or unions, wierd macros, bit fields, etc. I think Araq was aiming for c89 standards when he wrote it.
01:03:39VarriountEXetoC, why are there stars in the sky?
01:04:47EXetoCthe question is that complex? nevermind then
01:05:12yoginVarriount: yeah, these things are expected when dealing with numbers, i'll try to compile GMP without C99 features, and then re-generate gmp.h.. May be not now
01:06:12Varriountyogin, I'll try translating things as well. Unfortunately, running windows, I might not actually get GMP to compile, in order to test the wrapper out.
01:06:53yogincygwin already has GMP there i think
01:06:59yoginif u r using cygwin at all
01:07:08VarriountI don't use cywin. Mingw32/64
01:07:54VarriountSomebody has to use windows, for support if nothing else. :/
01:08:49yoginnp, give it a try, if we can translate GMP, then Nimrod will have a bignum library, not only for integers, but also floats. That sounds so cool :)
01:09:25Varriountyogin, well, at least for whatever set of options you put into GMP for compiling.
01:09:50yogini know
01:18:39yoginok, gonna sleep now, let's catch up during weekend
01:18:40*brson quit (Read error: Operation timed out)
01:21:22*brson joined #nimrod
01:26:20Varriountyogin, so, the big problem with GMP at the moment is that it uses a *lot* of compiler-dependant variables to define stuff
01:28:12*MFlamer quit (Ping timeout: 272 seconds)
01:39:13*BitPuffin quit (Ping timeout: 272 seconds)
01:39:40*DAddYE quit (Remote host closed the connection)
01:40:16*DAddYE joined #nimrod
01:44:52*DAddYE quit (Ping timeout: 264 seconds)
01:52:14*EXetoC quit (Quit: WeeChat 0.4.2)
02:00:54*filwit quit (Quit: Leaving)
02:32:19*zahary1 quit (Read error: No route to host)
02:32:51*zahary joined #nimrod
02:33:38VarriountHi zahary
02:40:41*DAddYE joined #nimrod
02:45:02*DAddYE quit (Ping timeout: 240 seconds)
02:50:56*DAddYE joined #nimrod
02:55:51*DAddYE quit (Ping timeout: 272 seconds)
03:00:33*ics joined #nimrod
03:22:51*ics quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
03:27:11*ics joined #nimrod
03:42:39*DAddYE joined #nimrod
03:47:17*DAddYE quit (Ping timeout: 248 seconds)
03:51:06*xenagi joined #nimrod
04:02:16*zahary quit (Ping timeout: 248 seconds)
04:04:25*brson quit (Quit: leaving)
04:30:11*Trixar_za quit (Ping timeout: 245 seconds)
04:36:54*familiar125 quit (Read error: Connection reset by peer)
04:44:04*DAddYE joined #nimrod
04:44:39*Trixar_za joined #nimrod
04:48:16*DAddYE quit (Ping timeout: 240 seconds)
04:53:44*OrionPK quit (Read error: Connection reset by peer)
04:53:49*Associat0r quit (Quit: Associat0r)
05:27:46*DAddYE joined #nimrod
05:28:03*DAddYE quit (Remote host closed the connection)
05:28:10*DAddYE joined #nimrod
05:32:53*xenagi quit (Quit: Leaving)
08:28:38*BitPuffin joined #nimrod
08:32:41*BitPuffin quit (Read error: Operation timed out)
08:50:44*Jackneill joined #nimrod
09:11:56zahary_hi Varriount, I was sleeping when you tried to reach me (most of us are in Europe)
09:25:44*CarpNet joined #nimrod
09:47:23*BitPuffin joined #nimrod
09:48:07BitPuffinGood * guys?
09:48:10BitPuffin!
09:48:12BitPuffin*
09:48:14BitPuffinRH;AERC;He
09:49:34*Associat0r joined #nimrod
09:49:34*Associat0r quit (Changing host)
09:49:34*Associat0r joined #nimrod
09:53:30*Associat0r quit (Client Quit)
10:30:32BitPuffinvery dead in irc today
10:30:37BitPuffinmust be because it is friday
11:15:04*Associat0r joined #nimrod
11:15:04*Associat0r quit (Changing host)
11:15:04*Associat0r joined #nimrod
11:35:05*Associat0r quit (Quit: Associat0r)
11:51:40BitPuffinWhat's the best way to make an interface for nimrod?
11:51:47BitPuffinTo ensure that everything gets implemented
11:52:06BitPuffinand get polymorphism etc
11:52:45BitPuffinI'm thinking about later when I possibly make a game api thing
11:53:42BitPuffinSo take the case of linagl, in a macro which generates shaders for example, I'd like to have the same API as everywhere else, just that the implementation of the shader generator is different
11:54:59BitPuffinAnd I don't really want to have to do it all within linagl, I want to be able to implement it where it is used
11:57:17BitPuffinBut I don't really want you to have to instantiate a linagl object either because that's absolutely stupid
12:01:16BitPuffinhmm I'm actually getting some ideas on how it could be possible
12:05:02*dymk quit (Ping timeout: 264 seconds)
12:05:35BitPuffinmaybe I should take a look at how the compiler generates C, js and so on :P
12:14:43*dymk joined #nimrod
12:51:06zahary_I guess we need to add abstract/mandatory methods; some pragma will be used to mark them
12:54:03*Ricky_Ricardo joined #nimrod
13:05:47BitPuffinzahary_: yes that would be quite nice
13:06:22BitPuffinzahary_: however like I said I am not really talking about linagl objects or whatever
13:06:51BitPuffinzahary_: more something like if I do VertexShader: ...... the linagl API has a different implementation
13:08:18*Jackneill quit (Ping timeout: 272 seconds)
13:08:31BitPuffinand not only that it would be cool to have some kind of interface that all of them share, so that you can change the interface and be forced to make the api consistent across different implementation
13:08:32zahary_well, that doesn't require run-time polymorphism. this is just a matter of modifying what's in the current scope
13:08:33BitPuffins
13:09:46BitPuffinand also some way to subset an api, so in the context of a shader, TVector and TMatrix could not be used but istead you'd have to use fix sized types like TVec3 TMat2 and so on
13:09:58BitPuffinzahary_: sure, but runtime polymorphism would be nice to have too
13:11:31zahary_there are two ways to implement such "scope-specific" lookups and rules. the first one is that you have a VertexShader template that defines a bunch of other templates before processing the user code
13:11:43zahary_the suite template in the unittest library is an example for this:
13:11:44zahary_https://github.com/Araq/Nimrod/blob/master/lib/pure/unittest.nim#L46
13:12:12zahary_the other newer method is to use the "using" keyword for similar effect
13:12:36BitPuffinyeah using came to mind when I was pondering it earlier
13:13:03BitPuffinbut I guess using is more a runtime construct perhaps?
13:13:29zahary_no, it modifies only the scope lookup rules
13:13:46BitPuffinah
13:14:00BitPuffinso then perhaps it could do the job
13:14:26BitPuffinbut basically I'd like a way to do using glslLinaglImpl:
13:16:23BitPuffinI guess what would be really nice would be to use "standard" linagl variables in the glsl implementation. What I mean is to for example have a proc that takes a standard TVec4 for example, and as that fits within the GLSL subset of linagl, I can implement a way to convert it into the GLSL type in the transformation
13:16:41BitPuffinin this case it would be setting up uniforms or properties or whatever that is sent to the vertex shader
13:16:54BitPuffinam I making any sense? lol
13:17:28BitPuffinso I guess that is kind of the polymorphism aspect I was referring to
13:18:26zahary_you just want your library to be generic; then it will work with nimrod types, glsl types and any other vector type the user throws at it
13:19:07BitPuffinzahary_: it is generic
13:19:18BitPuffinbut I don't want to put the extending stuff in linagl itself
13:19:22BitPuffinthat could grow to be huge
13:19:42BitPuffinI want to be able to reimplement the api in some other library
13:20:02zahary_what do you mean exactly when you say "reimplement the api"?
13:20:35BitPuffinzahary_: well so let's continue with the example of shaders
13:21:12BitPuffinIf I have to write every single possible way that linagl could work in the standard linagl implementation it would grow huge
13:21:40BitPuffinso say just standard math on the cpu, glsl, hlsl, I dunno xbone shaders, ps3 shaders etc etc
13:21:50BitPuffinI mean the different ways to do it is limitless basically
13:22:04BitPuffinthis is to help with portability
13:23:47zahary_but what do you want to do? you want to translate the calls to your library to the native calls in glsl?
13:24:24BitPuffinzahary_: yes
13:24:29BitPuffinor let's just take rendering in general
13:24:37zahary_so you need to enumerate all "translatable" calls and give the implementator an opportunity to define them all for his platform (and to make sure none of them is missed)?
13:24:49BitPuffinI wanna make a slightly higher level rendering api
13:25:23BitPuffinso I want to be able to have an opengl backend, direct3d backend, ps3 gpu stuff etc
13:25:49BitPuffinzahary_: yeah that sounds about right
13:25:55zahary_well, this doesn't require much more than supporting row-major vs column-major matrices
13:26:14BitPuffinit does
13:26:25zahary_if you want to compile shaders from nimrod proc definitions, that's another story
13:26:37BitPuffinzahary_: that's one thing I wanna do
13:26:48BitPuffinbut I was not just describing linagl now
13:26:52BitPuffinI mean an entire rendering api
13:27:06BitPuffinthat has an opengl backend, d3d backend etc etc etc
13:27:23BitPuffinand not have to implement it in the core files them selves like when bla, when bleu, when blarg
13:27:48BitPuffinbasically have an easy way for others to be able to change the implementation without having to modify the source
13:29:59BitPuffinso let's imagine someone uses my api to make a game and they want to port it to some alien platform, I don't want them to have to fork the api project, but rather I'd like to define some backends that they would have to implement in order to make it run
13:30:10zahary_it would be silly to base this on run-time polymorphism. instead let the user decide, which backend he wants at compile-time.
13:30:20BitPuffinyeah exactly
13:30:28zahary_then the backends just need to conform to the same informally defined API
13:30:32BitPuffinso methods don't cut it
13:30:36BitPuffinexactly
13:30:56zahary_to ensure conformance, you just need test cases. if the opengl API doesn't support something, compiling the test cases will fail
13:31:26BitPuffinyeah but that's kind of the ghetto way to do it I think
13:31:29BitPuffinlol
13:32:01BitPuffinand overly complicated, because I'd need to come up with ways to test if they actually implemented it
13:32:15BitPuffinso they should not even compile if they haven't implemented it
13:32:29BitPuffinand of course it is a very extremely good idea to have tests too
13:32:36BitPuffinbecause maybe they implemented it incorrectly
13:33:03BitPuffinbut that comes after the fact that they at least implement it, even if it is an empty proc or whatever
13:33:17zahary_it seems pragmatic enough to me, but the built-in mechanism to test conformance to a given generic interface is by defining a type class
13:33:23zahary_APIBacked = generic
13:33:35zahary_DrawPrimitives
13:33:41zahary_Present, etc
13:33:48BitPuffinsure
13:33:53BitPuffinis that already supported?
13:33:57BitPuffinoh and also!
13:34:05BitPuffinI don't want them to have to implement ALL of the API
13:34:09zahary_yes, but you may run into some bugs
13:34:10BitPuffinonly what they use in their application
13:34:29BitPuffinso I mean say that they only use DrawPrimitives or whatever
13:34:48*krusipo quit (Ping timeout: 252 seconds)
13:35:01BitPuffinthey shouldn't have to implement Present, PlaySound, ReadFile etc
13:36:27*krusipo joined #nimrod
13:37:30BitPuffinzahary_: I don't see the example pseudo code syntax thing you showed anywhere in the fm
13:37:57zahary_the type classes synta?
13:38:06BitPuffinyeah
13:38:18zahary_http://build.nimrod-lang.org/docs/manual.html#user-defined-type-classes
13:38:42BitPuffinoh
13:38:47BitPuffinso it was in the git manual :P
13:39:21BitPuffinwait a minute
13:39:28BitPuffinthere is a nimrod-code and a nimrod-lang website?
13:39:34BitPuffinDo they point to the exact same page?
13:39:40BitPuffinBecause that's not good SEO
13:39:52zahary_yes, nimrod-lang is taking over
13:40:45BitPuffinalright so change nimrod-code to a redirect then
13:41:08BitPuffinBecause otherwise we land even lower in google searches than we already do :P
13:41:11zahary_I think it already does
13:41:21BitPuffinoh it does yeah
13:41:24BitPuffinlol!
13:41:29BitPuffinwhen the hell did this happen :D
13:55:29BitPuffinlink to the manual should really be added to the build.nimrod-lang.org page
13:59:32*Ricky_Ricardo quit (Quit: laptop[lid].close)
14:10:32*isenmann quit (Quit: Leaving.)
14:11:08*Ricky_Ricardo joined #nimrod
14:15:10*Associat0r joined #nimrod
14:15:10*Associat0r quit (Changing host)
14:15:10*Associat0r joined #nimrod
14:25:11BitPuffinzahary_: will the type classes thing allow me to just implement what is used though?
14:26:36zahary_no, that would be possible only if you use regular generic procs without constraints
14:27:12zahary_or if you have several levels of conformity defined as type classes and check only for the most basic conformity.
14:28:12BitPuffinzahary_: but generic procs don't really provide the whole api thing
14:28:27BitPuffinjust a part of it
14:28:53zahary_they provide compile time switching, but lack the conformity checking
14:28:56BitPuffinand having levels of conformity doesn't make much sense, I should be able to check for complete conformity or conformity for what they are using
14:29:35BitPuffinor well not "I"
14:29:37BitPuffinthey
14:29:38zahary_well, generic procs do "what they are using" - the user will get a compile-time error if he didn't provide the necessary function
14:29:47BitPuffinyep
14:30:05BitPuffinbut it doesn't solve the whole thing
14:30:13BitPuffinit doesn't enable the whole backend thing
14:30:25zahary_why not?
14:30:26BitPuffinonly to write code that uses the backend
14:30:31BitPuffinbut not a way to implement the backend
14:30:45zahary_well, the backend is just a regular nimrod module
14:30:57BitPuffinyes
14:31:27zahary_you just need the user to supply it with some -d:backend=foo switch
14:31:33BitPuffinyup
14:31:37BitPuffinwhich is exactly what I want
14:32:11BitPuffinbut then in MY API I have to do, when defined(backend): bla; elif defined(backend2) etc
14:32:21BitPuffinwhich makes it so that they are forced to fork
14:32:25BitPuffinand it isn't separated
14:32:42BitPuffinI don't want the backend checking stuff to be monolithic
14:32:46zahary_no, you just have to import getDefined("backend") (do we have this already?)
14:33:33BitPuffinwell if so it does seem like it is doable
14:33:45zahary_when not defined("backend"): import opengl_backend
14:34:01BitPuffinfor default yeah
14:34:03*OrionPK joined #nimrod
14:34:20zahary_else: import (get_definition("backend")) # the compiler may require a patch for this, but it's very easy to implement
14:34:53BitPuffinhmm
14:34:57BitPuffinso it seems about right :D
14:35:20BitPuffinand there would probably be a mix of sorts
14:35:29BitPuffinor hmm
14:35:59BitPuffinyeah that in order to solve the whole api stuff
14:36:09BitPuffinand then something else in order to do the shaders thing
14:41:35BitPuffinzahary_: doesn't seem like -d:backend=foo makes a difference
14:41:45BitPuffinit still treats it as if it isn't defined
14:42:48BitPuffinhttps://gist.github.com/BitPuffin/7600940
14:43:11zahary_I think Nimrod currently support only on/off definitions, but I'm too busy now, I'll look into it tomorrow
14:43:30zahary_getDefinition was obviously pseudo code
14:44:15BitPuffinzahary_: ah, well in that case I should get a compile time error
14:44:23BitPuffinwith -d:backend=foo
14:44:51BitPuffinzahary_: no hurry, it is just something I've been pondering on how I would do it for a long time
14:45:00BitPuffinwithout it turning out to be a huge pile of shit
14:45:55BitPuffinthis seems like a pretty good way
14:48:12BitPuffinthis is really only one part of the api plans too, there are other ideas like making a server with runtime code reloading as you update the engine you are writing with the api, having it networked so that you can program the editor and update it and people using the editor get notified and can upgrade as they are editing and seeing the changes that others are making etc
14:48:22BitPuffin:P
14:48:26BitPuffinIt's a big project
14:48:54zahary_don't try to build one huge library, instead make it as fleet of libraries that can be used independently
14:49:06*Jackneill joined #nimrod
14:49:09BitPuffinzahary_: that is exactly the plan don't worry :P
14:49:46BitPuffinreusability is a huge thing for me
14:49:50BitPuffinand modularity
14:50:28BitPuffinand one of the reasons I put my stuff in the public domain is because I want people to be able to (legally) copy and paste code snippets from my open code in to their project
14:50:38OrionPKcopypasta ftw
14:50:51BitPuffinso being able to just snipe out what you want is important!
14:52:06BitPuffinthis is also why I want to add the feature to be able to invoke the compiler from code btw, haven't gotten around to adding that yet :P
14:52:33BitPuffinBut yes, enough talking about my plans
14:52:43zahary_invoke which compiler?
14:52:50BitPuffindon't want to set any expectations that there is a risk I can't live up to
14:52:53BitPuffinzahary_: nimrod
14:53:08BitPuffinwithout you know, executing it via the system
14:53:32zahary_invoking nimrod while compiling nimrod? that's too meta even for us
14:53:45BitPuffinzahary_: no while running nimrod
14:53:48BitPuffinas a procedure call
14:55:08BitPuffinimport compiler; compileFile("bla.nim", flagsandstuff)
14:55:44BitPuffinzahary_: of course I guess with import compiler; static: compileFile("bla.nim", flagsandstuff) would be at compile time lol :P
15:21:42Araqso ... how many closure related bug reports will you give me until you realize it's all the same issue?
15:45:49VarriountAraq, f(x) = x+1*u, where u is the number of people who encounter the bugs.
15:48:08VarriountAraq, would one of those bug reports be the one I submitted concerning inner closure-iterators?
15:48:10*EXetoC joined #nimrod
15:48:54*MFlamer joined #nimrod
15:56:12*MFlamer quit (Remote host closed the connection)
16:20:31*MFlamer joined #nimrod
16:20:33*BitPuffin quit (Ping timeout: 245 seconds)
16:38:30*silven_ joined #nimrod
16:38:50*silven quit (Ping timeout: 246 seconds)
16:47:26*silven_ quit (Quit: No Ping reply in 180 seconds.)
16:47:50*silven joined #nimrod
16:58:58*ics quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
17:06:13*Ricky_Ricardo quit (Quit: laptop[lid].close)
17:13:56C0C0how do I allocate a seq with n numbers
17:16:22C0C0never mind ^^
17:16:23C0C0found it
17:16:32EXetoCC0C0: both overloads of newSeq allows ... ok :>
17:18:45EXetoChttps://gist.github.com/EXetoC/7603547 bug?
17:19:22*Ricky_Ricardo joined #nimrod
17:19:32EXetoCI don't think I stumbled upon this the last time, but then again the interface has changed
17:20:21EXetoCI omitted the `div` proc, but that doesn't matter
17:26:27*ics joined #nimrod
17:28:23AraqEXetoC: iirc I fixed it and then zahary_ broke it again ...
17:28:56*DAddYE quit (Remote host closed the connection)
17:29:23*DAddYE joined #nimrod
17:33:41*brson joined #nimrod
17:34:23*DAddYE quit (Ping timeout: 272 seconds)
17:51:35*DAddYE joined #nimrod
17:51:36*DAddYE quit (Remote host closed the connection)
17:51:49*DAddYE joined #nimrod
17:58:20*silven quit (Ping timeout: 245 seconds)
17:58:49*silven joined #nimrod
17:59:41MFlamerAraq: For my pragma, do you see any problems(implementation, or style) with me using variant constructor syntax like "Just(69)" which would create a value of Maybe int for example?
18:00:09MFlamerAnother option might be injection "69 -> Just"
18:02:12AraqI like Just(69)
18:02:41Araqdo I see problems with the implementation? not any problems that we don't have already
18:02:43MFlamerthe second style might be easier to implement, but looks a little more cumbersome. For the call style syntax, I can see I would have to tweak the semantic checking in semcalls.nim, might be a little tricky, but good for experience
18:02:54MFlamerI agree, cool
18:03:13*silven quit (Client Quit)
18:03:31Araqindeed you need to check if X in X() is a enum value and if so it's a constructor
18:03:39*silven joined #nimrod
18:05:35Trixar_zaJust 69? You guys have some very dirty thoughts
18:19:16C0C0just?
18:19:25C0C0sounds rather tame doesn't it?
18:22:36MFlamerIt's a good start anyway
18:24:27C0C0^^
18:26:15*Ricky_Ricardo quit (Quit: laptop[lid].close)
18:26:22Trixar_zaForeplay huh? Oo
18:27:06MFlamerthis discussion is going downhill fast.....
18:37:18*CarpNet quit (Quit: Leaving)
18:42:42EXetoCAraq: ok
18:49:33*BitPuffin joined #nimrod
18:55:52leexHi, are the TQueues thread-safe?
18:57:02Araqthere are TChannels. they are meant for thread communication
18:57:19AraqTQueues are thread-local like anything else that is GC'ed
18:58:34*brson_ joined #nimrod
18:58:42leexAraq: thanks
19:01:03BitPuffinAraq: fun question, what keyboard do you use?
19:01:44Araqone with ä ö and ü
19:01:47*brson quit (Ping timeout: 272 seconds)
19:01:53C0C0^^
19:01:53EXetoCnice
19:02:16BitPuffinAraq: nice, but no ĂĄ, so me and EXetoC win
19:02:24BitPuffinAraq: but I ment which brand/model
19:02:49leexöäüß aka why do you win? ;)
19:03:28BitPuffinåöäëüïÿ
19:03:30BitPuffinµ
19:03:37EXetoCµ“þ®↓→ħ»ł€®
19:03:40BitPuffinþœłŋħ
19:04:02BitPuffinĸßæ
19:04:06Araqmy keyboard says it's a "Medion"
19:04:10EXetoCBitPuffin: does your generic codez work fine on a recent Nimrod build?
19:04:40BitPuffinEXetoC: not the latest push on its own bookmark (branch)
19:04:44OrionPKyou guys are trying to crash my IRC client with your crazy unicode arent u
19:04:45BitPuffinbut otherwise it should work
19:04:50BitPuffinalthough it is incomplete
19:05:07BitPuffinAraq: I was expecting you to have a more nerdy keyboard since you are a programmer :P
19:06:07BitPuffinI'm contemplating getting one of these http://pckeyboard.com/page/category/Classic
19:06:33BitPuffinEXetoC: although I'm gonna fix it like probably this weekend
19:06:37BitPuffinwell it can't be fixed
19:06:43BitPuffinsince there are compiler bugs
19:06:45BitPuffinbut you know
19:06:47BitPuffinworkaround
19:07:16BitPuffintemporarily make det only work for fixed size matrices
19:07:28BitPuffininstead of n-dimensional
19:07:29BitPuffinor hmm
19:07:38BitPuffinactually I came up with a workaround now that I remember
19:08:00EXetoCright
19:16:04EXetoCI'll simply not bother with a generic vector type for now. it's overkill in my case
19:16:44BitPuffinEXetoC: meh come on you gotta use linagl :D it's the best thing in the universe!
19:17:58BitPuffinI'll fix it up for you
19:18:08EXetoCbut I wanna re-invent the wheel!
19:18:12BitPuffinNOOO
19:18:29BitPuffinEXetoC: by the way if you want something basic fowl has vector stuffs
19:18:49EXetoCnah I'll use it
19:19:31*brson_ quit (Quit: leaving)
19:19:47*brson joined #nimrod
19:28:29EXetoCBitPuffin: how about that game? do you know how to implement culling, ray casting etc?
19:30:51*MFlamer quit (Remote host closed the connection)
19:32:36*brson_ joined #nimrod
19:35:50*brson quit (Ping timeout: 245 seconds)
20:10:12*Ricky_Ricardo joined #nimrod
20:12:19leexI am getting this error: Error: ambiguous identifier: 'TThread' -- use a qualifier and I am not quite sure what's wrong, any ideas?
20:12:40leexthe line nimrod complains about is this: thr2: array[0..4, TThread[tuple[a,b: int]]]
20:12:49leexand I am compiling with --threads:on
20:22:59EXetoCI got that before, but with some other identifier. I had to qualify the symbol with the module name
20:24:03leexEXetoC: thanks!
20:25:24EXetoCbut I don't know if it is an expected change
20:28:38EXetoCit seems to be, according to the latest documentation
20:33:58BitPuffinEXetoC: what game?
20:35:20EXetoCactually I'm not sure, but I wouldn't want to have to explicitly inject every operator for a vector type for example, because it's very tedious
20:36:10BitPuffinEXetoC: inject?
20:36:11EXetoCBitPuffin: the game you wanted us to help you with
20:36:23BitPuffinI wanted you to help me with a game?
20:36:55EXetoCI guess not, since you're asking, so nevermind
20:37:27EXetoCBitPuffin: yes. it seems like I have to qualify with the module name, unless I explicitly import every symbol that I want to use
20:37:54BitPuffinanyways with ray casting don't you basically ray trace without tracing the bounces?
20:38:17EXetoC`-`, `+` etc. there was no need to qualify symbols before unless necessary because of a collision
20:39:19BitPuffinEXetoC: hmm show me your code
20:39:25BitPuffinI'll take a look
20:41:08BitPuffinand fix it
20:42:27EXetoCdoes "import x" behave differently now?
20:42:46BitPuffinEXetoC: var v: TVec3 = [2.0f32, 84.2f32, 8.2f32]; var b = 2*v should work
20:42:53BitPuffinunless I've fucked something up while refactoring
20:43:02BitPuffinEXetoC: not that I know of
20:43:03EXetoCno not your code
20:43:07BitPuffinoooh
20:43:08EXetoCok
20:43:15BitPuffinI thought there was a problem with linagl
20:43:17BitPuffinphew
20:43:19BitPuffinwel
20:43:21BitPuffinhehe
20:43:24BitPuffinthere are lots of problems
20:43:29BitPuffinor well not really
20:43:34BitPuffinjust minor ones
20:43:53EXetoC"import vec"; initVec(...); # broken ..... vec.initVec(...) # works
20:43:56EXetoCsomething like that
20:44:45EXetoCfrom vec import `-`, `+`, `*` # hopefully not necessary :p
20:45:34BitPuffinhmm, wtf
20:45:45BitPuffinand that's not generic?
20:45:54Araqimport didn't change
20:46:11BitPuffinimport.... import never changes
20:46:31EXetoCgeneric?
20:46:56BitPuffinEXetoC: the initvec
20:47:01EXetoCwill make a test case some time. this might be related to what leex was asking about
20:47:05EXetoCBitPuffin: yes
20:47:08EXetoCbbs
20:47:14BitPuffinbbs?
20:47:36BitPuffinThe Romans waged war to gather slaves and wealth. Spain built an empire from its lust for gold and territory. Hitler shaped a battered Germany into an economic superpower.
20:47:39leexEXetoC: all I forgot was a system.
20:47:40BitPuffinBut nimrod never changes
20:48:05BitPuffinimport*
20:53:43AraqChannel support for threads. Note: This is part of the system module. Do not import it directly.
20:54:02Araqthreads Nimrod thread support. Note: This is part of the system module. Do not import it explicitly.
21:01:21BitPuffinAraq: pwnd
21:01:52BitPuffinmaybe there should be some kind of compiler warning or something when you import them
21:02:03BitPuffinor even fatal compilation
21:04:56BitPuffinhmm, or maybe it is better to learn the hard way ;D
21:06:51BitPuffinthat way you never forget
21:06:55Araqactually
21:07:03Araqit's easy to do that with a hack :-)
21:07:10Araqand it's a good idea
21:08:05*gradha joined #nimrod
21:08:24leexwhat's the correct/nimrod way for getting shared memory for threads
21:08:28BitPuffinAraq: you mean compilation termination?
21:08:57BitPuffinleex: shared keyword perhaps?
21:09:41BitPuffinor maybe it's {.shared.}
21:10:39Araqleex: there is allocShared but then you need to deal with the memory yourself
21:11:03Araqwe also have a lockfree hash table but I don't know the status of it
21:11:20AraqBitPuffin: 'shared' is a keyword but not implemented
21:11:39*Ricky_Ricardo quit (Quit: laptop[lid].close)
21:11:52AraqBitPuffin: I mean when not isSystemModule: {.error: "do not import this module. it is part of system".}
21:11:59BitPuffinAraq: ah, I suspected something like that
21:12:28BitPuffinlooks easy enough :D
21:13:34*Jackneill quit (Remote host closed the connection)
21:13:46*ics quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
21:16:08leexwhat does "Error: type expected" mean?
21:16:23BitPuffinthat a type was expected
21:16:41leexBitPuffin: ;) well I am calling a function
21:21:58BitPuffinleex: how does the proc look?
21:28:35BitPuffinleex: I wanna herp you :D
21:31:39C0C0derp
21:31:56C0C0BitPuffin: I derped him for you
21:32:04leexBitPuffin: I am building a minimal failing example, because it's rather huge ;)
21:32:29gradhaleex: don't worry about minimal examples, post first, ask later if its too big
21:33:06leexgradha: :D
21:33:09BitPuffinC0C0: good jerb
21:33:26*gradha fears the herptiles walking among us
21:33:43BitPuffinleex: well you just have to show the proc signature of the proc that says type expected and how you are calling it
21:33:58leexhttp://pastebin.com/Vx3PFGL6
21:34:58leexBitPuffin: and the error is: minfail.nim(12, 0) Error: type expected
21:36:09BitPuffinleex: try foo_update_img(tile = job)
21:36:12gradhayou are using : but should be using =
21:36:12BitPuffinI'm not sure that's it
21:36:24gradhathen the error is more understandable
21:37:25gradhaI can see that's confusing as : is used for object constructors
21:37:54BitPuffinyeah
21:37:58BitPuffinit really should also be =
21:38:01leexyeah!
21:38:03leexthanks a lot
21:38:13BitPuffinno problem leex, have fun :D
21:38:33gradhaleex: also you don't need to specify the name of the parameter
21:39:35leexBitPuffin: thanks :)
21:40:05leexgradha: but it's so nice to name them, I really enjoy naming them explicitly
21:43:19gradhayou'll note that's not very usual in nimrod land, a quick look at any module (eg. system) will show a lot of procs with one letter names
21:44:34gradhathe idea around here is to use better tooling which will autocomplete/suggest/display help while you code
21:45:20*gradha wonders if dom96 has already implemented for Aporia docstring visualization while calling a proc
21:46:27BitPuffinleex: I like doing it to, I'm just very sloppy about it
21:46:35BitPuffinI think it's great for readability of the code
21:47:21gradhahopefully for you guys readability != length, or you will end up with objc's naming convention clusterfuck
21:47:23leexhow do I get the ref of a variable?
21:47:34Araqgradha: what you say is true, however, what do you think the parameter names for `+` should be named?
21:48:05gradhaAraq: one letter variables, why?
21:48:44Araqalright then the system module is not the best example
21:49:52Araqactually Perl 6 has somethink like proc foo(longName as L: int) and then you can use L in 'foo' but people can use foo(longName=bar)
21:49:56Araq*something
21:50:14gradhaI was thinking maybe you can forward declare a proc with a long name and use it later with a shorter one for convenience
21:50:31BitPuffinAraq: we were actually referring to when calling
21:50:32BitPuffinI think
21:50:56BitPuffinso connect(url = "http://google.com", port = 1337)
21:51:09BitPuffinestead of connect("http://google.com, 1337)
21:51:20AraqBitPuffin: I know
21:51:29BitPuffinah
21:51:38gradhaBitPuffin: heresy! next you will say people read documentation
21:51:58AraqI liked Perl 6's idea but considered it not worth the implementation trouble
21:52:06BitPuffinI thought you meant that we suggested that with + you shouldn't name the params a and b
21:52:17Araqnow I think we might introduce it
21:52:17BitPuffinbut I think with operators you shouldn't name the parameters
21:52:56BitPuffinbecause with operators it is so stupidly incredibly clear that they are the operands
21:53:33AraqBitPuffin: when you read the conversation again, my point should become clear
21:54:21BitPuffinyeah probably, I was really only skimming
21:54:24leexhow do I get the reference of a variable, like addr(variable) but well not the ptr, but the ref
21:54:26BitPuffintoo busy drooling over the model m
21:55:03leexBitPuffin: still on the hunt for a new keyboard?
21:55:17BitPuffinleex: you knew I was on the hunt?
21:55:54leexwell, from earlier when you asked Araq
21:55:59BitPuffinah
21:56:04gradhaleex: references are "safe", and variables on the stack are not, so you can only get ptr, which is unsafe
21:56:05BitPuffinwell I'm just considering buying it
21:56:19BitPuffinI mean it's got the best key switches out there
21:56:28BitPuffinbut there are two drawbacks
21:56:36leexBitPuffin: I thought about a model m but then I bought a cherry
21:56:48gradhaleex: you would need to create a referenced version of your object and copy the data into it if you really really want a ref version
21:57:43BitPuffinthere is no tenkeyless/compact model, and it is 2KRO, so only 2 keys are guaranteed to get recognized at the same time, but of course they usually respond more than two it's just a minimum
21:57:47BitPuffinleex: how so?
21:58:33leexgradha: well, I have a Queue object, which I would like share it among threads and lock it myself. what would be the way to do it?
21:58:47*ics joined #nimrod
21:59:02BitPuffinleex: or I mean why so
21:59:45gradhaleex: sorry, no idea, haven't touch threading in nimrod yet
22:00:43leexBitPuffin: a friend of mine got it and I tried it and it's really great with the MX Blue switches
22:00:47leexgradha: ok, thanks ;)
22:01:29Araqleex: the locking won't safe you, you can't share memory like you intend to do
22:01:51Araqyou can use a channel though
22:01:58BitPuffinleex: ah, yeah they are nice
22:02:22Araqor implement your own queue which uses allocShared
22:02:28*MFlamer joined #nimrod
22:02:35leexBitPuffin: and it's like 50Euro, so it's rather cheap compared to other keyboards
22:02:45leexAraq: ok
22:02:50Araqor ask MFlamer about the status of his lockfree hash table
22:02:54*ics quit (Client Quit)
22:03:02Araqand how to implement a lockfree queue
22:03:42MFlamerI'm back
22:04:17BitPuffinleex: mx?
22:06:25BitPuffinleex: If I am getting an mx keyboard it is definitely gonna be filco majestouch 2 tenkeyless
22:08:07leexBitPuffin: well, that's nice, but the switches are the same as in the cherry keyboards and they don't set you back 200Euro
22:08:30BitPuffinleex: well but there is also the overall build quality
22:08:39leexBitPuffin: I got the cherry g80 3000 with MX Blue switches
22:09:06*OrionPK quit (Read error: Connection reset by peer)
22:09:17leexBitPuffin: well, yeah but 150 for plastic ;) if I would ever spend so much money on a keyboard I would get a kinesis
22:11:23BitPuffinleex: yeah I am also considering the TECK
22:13:42leexBitPuffin: never tried one of those
22:15:07*Ricky_Ricardo joined #nimrod
22:15:57BitPuffinleex: but I have a feeling I want the model m
22:16:08BitPuffinjust that I really really want a tenkeyless :(
22:16:48leexhttp://pastebin.com/XzbYfbt8 yeah, a new error ;)
22:16:57leexand again a really small version of it
22:17:24BitPuffinlet me take a look
22:17:30leexBitPuffin: thanks
22:19:20BitPuffinleex: why do you take void as a parameter
22:19:34BitPuffinI don't even know if that is valid lol
22:19:36BitPuffinnever seen it
22:20:07leexBitPuffin: well, I cannot do just system.TThread[] or system.Thread
22:20:19leexso I though I would go with void :D
22:20:36BitPuffinwhat's wrong with proc threadFunc()
22:21:18BitPuffinand createThread(thr[i], threadFunc)
22:23:21leexBitPuffin: well, then either I get a type mismatch if I do system.TThread[void] or I get an illformed AST for system.TThread[] or an invalid type for TThread
22:24:52BitPuffinahh
22:24:53BitPuffinhmm
22:26:18BitPuffinleex: maybe TMsg is a good thing to default to
22:26:21BitPuffinbut I don't really know
22:26:26BitPuffinI haven't done much threading
22:27:52leexwell, it must be possible to get a thread without a parameter...
22:29:26BitPuffinleex: what happens if you pass nil?
22:30:07BitPuffinAraq: halp
22:30:14leex;)
22:39:52*OrionPK joined #nimrod
22:41:59*brson joined #nimrod
22:44:30gradhaleex: the only thing I can tell you is that it works if you pass anything http://pastebin.com/uRTyP5xT
22:44:33*brson quit (Client Quit)
22:44:38gradhamaybe there is a problem with void?
22:44:49*brson joined #nimrod
22:44:53*brson_ quit (Ping timeout: 248 seconds)
22:45:10leexgradha: I actually went for that fix a while ago ;)
22:45:31leexgradha: but still I would like to understand why it doesn't work with void
22:45:49gradhaleex: are you using the stable nimrod or git version?
22:46:03fowlleex, your problem is proc threadfunc(void)
22:46:16fowlleex, this is saying that void is a generic argument
22:47:03leexgradha: I am using a month old git version
22:47:14leexfowl: ok, so what should I do?
22:47:26gradhafowl: I tried not passing anything, still errors http://pastebin.com/kvBtRy50
22:49:24Araqvoid is not a value
22:49:28Araq createThread(thr[i], threadFunc)
22:49:31Araqshould work
22:49:46fowlcreateThread[void](args)
22:51:46gradhaAraq: doesn't work for me until specifying [void] like fowl says
22:52:44Araqoh yeah
22:53:01AraqcreateThread[void](thr[i], threadFunc) should be it
23:10:41*Amrykid quit (Excess Flood)
23:10:47*Amrykid joined #nimrod
23:19:45gradhaI'm starting to believe Wikipedia and Apple are run by the same people
23:20:52gradhafor the price of an iphone 5s 32gb you can get a nexus 5 32gb + nexus 7 32b + extra cash to spend on hookers
23:30:00gradhagood night
23:30:06*gradha quit (Quit: bbl, need to watch https://www.youtube.com/watch?v=2IzR_ClTE8Y again)
23:35:52C0C0is there a comfortable way to benchmark how many objects are created of which types?
23:35:59C0C0(as in: "on the heap")
23:39:20C0C0never mind
23:39:36C0C0found nimrod-lang.org/estp
23:41:34*faassen joined #nimrod
23:45:17C0C0different question: I have a main thread which spawns a set of worker threads
23:45:32BitPuffinthat's not a question
23:45:36C0C0these worker threads are supposed to write to a common image in memory
23:45:47C0C0we are currently using Locking
23:45:54C0C0and write to the global variable
23:46:05C0C0which breaks on the first GC iteration
23:46:24C0C0passing the image around as a huge binary object is not cool
23:46:41BitPuffinC0C0: why not split it up to parts and combine it afterwards
23:47:02BitPuffinor communicate through channels
23:47:05C0C0thats the problem
23:47:15BitPuffinsay you have worker threads that determine what should be written
23:47:24C0C0the threads will update different parts of the image at different times
23:47:29C0C0but repeatedly
23:47:33BitPuffinthen they'll just send the values through a channel to a thread that just puts it there
23:47:35BitPuffinno computation
23:47:38*Ricky_Ricardo left #nimrod (#nimrod)
23:47:39BitPuffinjust putting it
23:47:50C0C0e.g. the entire image is written once
23:47:52BitPuffinC0C0: will they ever update the same as any other?
23:48:00C0C0then the next iteration is performed
23:48:21C0C0(path tracing - every thread updates a single 32x32 pixel block)
23:48:30C0C0then the block is added to the image
23:48:31BitPuffinalrighty then
23:48:44BitPuffinso just give them each a slice of the full image
23:48:46C0C0so I guess I could just send the block data through a channel
23:49:11BitPuffinbut yeah the channel way is probably the right way to do it
23:49:19C0C0the doc says channels are slow
23:49:24BitPuffinoh?
23:49:25C0C0so i was afraid of using them
23:49:30BitPuffinwell then do the slicing thing
23:49:32BitPuffinor hey
23:49:35BitPuffindo both and compare
23:49:42C0C0how do I do the slicing thing?
23:49:50C0C0whatever the "slicing thing" is
23:49:51BitPuffinI'm not entirely sure
23:50:09C0C0ok what I am currentl doing:
23:50:15C0C0i have 8 threads
23:50:24BitPuffinbut basically one worker gets a pointer to the first 1/n of the image
23:50:34BitPuffinokay so the first eighth
23:50:41C0C0and I seperate the image into m pieces of size 32x32
23:50:51C0C0now i place all of them in a queue
23:50:55BitPuffinand then another thread gets a pointer to the second 8th of the image
23:50:59C0C0now all workers will aqure a lock
23:51:13C0C0get a pointer to the 32x32 patch from the queue
23:51:23C0C0use it exclusively
23:51:26BitPuffins/pointer/reference
23:51:29C0C0ref
23:51:35C0C0yeah ref all the things
23:51:48BitPuffinbut yeah basically
23:52:02BitPuffinif the threads cannot access the data that the other threads write
23:52:03C0C0when its done it aquires another lock, puts the changes into the global image and reappends the patch to the queue
23:52:08BitPuffinI don't see how there can be a lock
23:52:28BitPuffinwell if you just divide the memory up it shouldn't need to patch it
23:52:37BitPuffinI think at least
23:52:58C0C0well the problem is not that threads interfer with each other but that the garbage collector crashes
23:53:10BitPuffinhmm
23:53:12BitPuffinwell try ptr then :P
23:53:17C0C0hmm
23:53:20BitPuffinand bug report perhaps not sure
23:53:26BitPuffindiscuss with Araq
23:54:07BitPuffinC0C0: or actually try channels first
23:54:13C0C0yeah
23:54:15BitPuffinthey might be fast enough for what we know
23:54:16leexwell, if I compile with --gc:none, we run out of mem quite fast, but everything works nicely ;)
23:54:36BitPuffinlol
23:54:41BitPuffinwell the gc should not crash
23:54:46BitPuffinthat must be a bug or something
23:54:54BitPuffinso it is probably a good idea to report
23:54:56fowltry using a regular ptr for the texture then
23:55:00fowllike BitPuffin suggested
23:55:06C0C0even when writing to foreign heaps?
23:55:17C0C0fowl: I'll have a try
23:56:07BitPuffinwell the reason I said try channel way first is because if it is good enough you win because you are still leveraging gc
23:56:22BitPuffinso there is (unless gc has a bug) guarantee that you aren't leaking memory :P
23:56:30BitPuffinbut ptr will no doubt be faster
23:57:39BitPuffinand as the implementation of channels gets better it will increase perf too :D
23:59:25C0C0^^