00:45:08 | * | rubino123 quit (Quit: Leaving) |
01:17:27 | * | DAddYE quit (Remote host closed the connection) |
01:17:47 | * | DAddYE joined #nimrod |
01:18:58 | * | DAddYE quit (Remote host closed the connection) |
01:19:32 | * | DAddYE joined #nimrod |
01:23:53 | * | DAddYE quit (Ping timeout: 245 seconds) |
01:38:57 | * | Associat0r quit (Read error: Connection reset by peer) |
02:08:49 | * | q66 quit (Quit: Leaving) |
02:20:04 | * | DAddYE joined #nimrod |
02:26:14 | * | DAddYE quit (Ping timeout: 240 seconds) |
03:23:13 | * | DAddYE joined #nimrod |
03:29:35 | * | DAddYE quit (Ping timeout: 245 seconds) |
03:37:31 | * | Raynes quit (Ping timeout: 240 seconds) |
03:38:29 | * | Raynes joined #nimrod |
04:26:22 | * | DAddYE joined #nimrod |
04:32:38 | * | DAddYE quit (Ping timeout: 240 seconds) |
04:43:14 | * | OrionPK quit (Quit: Leaving) |
05:29:28 | * | DAddYE joined #nimrod |
05:36:11 | * | DAddYE quit (Ping timeout: 264 seconds) |
05:41:37 | * | BitPuffin joined #nimrod |
05:54:04 | BitPuffin | Araq: Did you figure out what the problem was with the matrices? Why I couldn't do C.low etc |
05:59:58 | * | DAddYE joined #nimrod |
06:29:41 | * | wan_ quit (Quit: ChatZilla 0.9.90.1 [Firefox 22.0/20130625173050]) |
07:16:18 | * | fowl quit (Ping timeout: 256 seconds) |
07:17:30 | * | Endy joined #nimrod |
07:22:35 | * | BitPuffin quit (Quit: No Ping reply in 180 seconds.) |
07:22:53 | * | BitPuffin joined #nimrod |
07:27:44 | * | fowl joined #nimrod |
07:50:52 | * | BitPuffin quit (Quit: No Ping reply in 180 seconds.) |
07:54:10 | * | Associat0r joined #nimrod |
07:54:10 | * | Associat0r quit (Changing host) |
07:54:10 | * | Associat0r joined #nimrod |
07:55:38 | * | BitPuffin joined #nimrod |
08:16:07 | * | Endeg quit (Ping timeout: 264 seconds) |
09:08:13 | dom96 | hello |
09:08:22 | Araq | hi |
09:09:06 | * | DAddYE quit (Remote host closed the connection) |
09:09:38 | * | DAddYE joined #nimrod |
09:14:49 | * | DAddYE quit (Ping timeout: 276 seconds) |
09:19:32 | BitPuffin | hey dom96 and Araq |
09:19:38 | dom96 | hey BitPuffin |
09:19:45 | BitPuffin | whaddup? |
09:20:35 | BitPuffin | What should I do if the return type is none, one or more of many, many different things? |
09:20:43 | BitPuffin | (for the collada loader) |
09:21:16 | Araq | return a Json object |
09:21:33 | BitPuffin | Araq: You sure? isn't there a better nimrod native type? |
09:22:15 | dom96 | Create your own custom type? |
09:22:42 | BitPuffin | well |
09:22:51 | BitPuffin | I was thinking about creating a type for every thing |
09:22:56 | BitPuffin | TColladaMesh etc |
09:23:14 | BitPuffin | Hmm |
09:23:21 | BitPuffin | inheritance perhaps? |
09:23:36 | BitPuffin | they could all be an object of TColladaResource |
09:23:52 | BitPuffin | so the return type could be an array of TColladaResources |
09:23:54 | dom96 | yeah, or you could use an object variant. |
09:24:20 | BitPuffin | Yeah that's true |
09:24:41 | BitPuffin | dom96: I guess make an enum that is resourcetype |
09:24:45 | dom96 | yeah |
09:25:00 | BitPuffin | yeah that should work out pretty nicely |
09:25:04 | BitPuffin | thanks |
09:25:19 | BitPuffin | anyways Araq I don't know if you saw what I wrote earlier |
09:25:33 | BitPuffin | actually maybe you could be of help here too dom96 :) |
09:25:45 | BitPuffin | https://bitbucket.org/TheLonelyByte/linagl/src/25fa332cee272a662115f94e60ed87cd81c20041/src/linagl/matrix.nim?at=tip |
09:25:58 | BitPuffin | I can't call high and low |
09:26:03 | BitPuffin | on the ranges |
09:29:14 | Araq | BitPuffin: it's not easy to fix |
09:29:33 | Araq | otherwise I would already have done it, I told you I looked at that code |
09:30:10 | Araq | try TMatrix[T, R, C] = array [R, array [C, T]] |
09:30:45 | Araq | you'd need to multiply the dimensions btw |
09:30:57 | Araq | unless I missed something |
09:31:09 | BitPuffin | Araq: awh :(, well I actually don't even want to do it that way, I guess it's better to wait for the generic values perhaps? |
09:31:39 | BitPuffin | Araq: and I don't know you well enough to know that just because you didn't say something it means that it's too hard to fix :) |
09:31:42 | BitPuffin | Yeah |
09:31:45 | BitPuffin | my bad |
09:32:00 | BitPuffin | rows + columns -.- |
09:32:09 | BitPuffin | sometimes you do idiotic things :D |
09:32:15 | Araq | 0.. rows*columns-1 |
09:32:48 | BitPuffin | Araq: the thing is that I don't want to use a multidimensional way because OpenGL is better at handling single dimenion |
09:33:16 | BitPuffin | :%s/way/array/g |
09:37:36 | Araq | opengl doesn't care |
09:37:43 | BitPuffin | I read that it did |
09:37:44 | * | [1]Endy joined #nimrod |
09:37:47 | BitPuffin | somewhere |
09:37:47 | Araq | as long as it's linearly laid out in memory |
09:37:55 | BitPuffin | maybe it was in the superbible |
09:37:56 | Araq | and that's what it is in nimrod |
09:40:19 | BitPuffin | hmm |
09:40:24 | BitPuffin | well then maybe it's juuust fine |
09:40:27 | BitPuffin | We'll see |
09:40:57 | * | Endy quit (Ping timeout: 264 seconds) |
09:40:58 | * | [1]Endy is now known as Endy |
09:41:31 | BitPuffin | that's also a bit easier to work with |
09:43:19 | BitPuffin | Araq: the only problem is that when you are writing the matrix literal, it will look wrong in code, since opengl traverses row major rather than column major. So you have to write the matrix transposed, and I'd like to have that happen in the background |
09:43:40 | BitPuffin | I guess just make a constructor or something |
09:53:01 | * | q66 joined #nimrod |
10:09:38 | BitPuffin | is there a way to restrict a field to only be possible some of the variants |
10:09:51 | BitPuffin | like if I have the variants a, b and c |
10:10:08 | BitPuffin | and in my object I want a field that can only be of kind b and c |
10:10:13 | * | DAddYE joined #nimrod |
10:11:37 | dom96 | of b,c: field: Type, is this what you have in mind? |
10:15:01 | BitPuffin | dom96: no I don't think so, unless I can also have a case inside the variant |
10:15:14 | BitPuffin | or actually that will probably not work either |
10:16:54 | dom96 | object variants do get a bit annoying when you have a field which you want to be shared for two variants. |
10:17:18 | * | DAddYE quit (Ping timeout: 264 seconds) |
10:18:49 | dom96 | in fact I would like for that to be improved, but Araq is busy enough as it is. |
10:19:57 | * | BitPuffin quit (Ping timeout: 264 seconds) |
10:22:20 | * | BitPuffin joined #nimrod |
10:23:03 | * | Endy quit (Ping timeout: 245 seconds) |
10:27:50 | * | BitPuffin quit (Ping timeout: 240 seconds) |
10:35:53 | * | BitPuffin joined #nimrod |
10:37:07 | * | Associat0r quit (Read error: Connection reset by peer) |
11:11:22 | BitPuffin | dom96: Hmm, well I wonder what I should do |
11:13:24 | BitPuffin | dom96: perhaps I'm worrying too much |
11:14:19 | dom96 | Could you explain in detail how you want it to behave? Maybe I can help you better. |
11:15:03 | BitPuffin | dom96: well so I'm creating a variant for all kinds of collada resources: mesh, animation and so on |
11:15:20 | BitPuffin | dom96: and these tags can all contain some of the other tags available (probably at least) |
11:15:43 | BitPuffin | dom96: but not all of the other tags, so I would like to restrict the kind of variant allowed in another variant |
11:15:52 | BitPuffin | if you grok what I mean |
11:16:39 | dom96 | hrm. |
11:16:46 | dom96 | So each resource can contain children. |
11:17:19 | dom96 | But each type of resource's children can only contain certain types of resources... |
11:17:53 | BitPuffin | dom96: yup, at least I think that's the way it is |
11:18:26 | dom96 | hrm, that's a toughie |
11:20:14 | BitPuffin | yep |
11:20:54 | dom96 | how would it be done in other languages? |
11:21:50 | dom96 | perhaps it's simply impossible to do at compile-time. |
11:21:57 | dom96 | or rather, with the type system. |
11:22:12 | dom96 | And you will have to check it at runtime. |
11:22:18 | BitPuffin | dom96: well I'm not sure how it would be done in a statically typed language, that's the problem, the only thing I can think of is casting |
11:22:20 | BitPuffin | but that's fugly |
11:22:48 | BitPuffin | either that or some odd template voodo probably :P |
11:22:59 | BitPuffin | I wonder how assimp does it |
11:23:11 | dom96 | yeah, I think template voodoo is your best bet. |
11:23:41 | BitPuffin | nimrod templates? |
11:23:51 | * | Endy joined #nimrod |
11:23:59 | BitPuffin | I can't seem to figure out how they would help though |
11:23:59 | dom96 | yeah, perhaps some 'add' template which checks the types for you |
11:24:07 | BitPuffin | maybe they can build a datastructure or something |
11:24:41 | dom96 | i'm not sure if you can check the field of your object variant which determines the type of your resource at compile time though |
11:25:48 | BitPuffin | no you can't |
11:26:30 | BitPuffin | argh |
11:26:36 | Araq | BitPuffin: you need a component system, both fowl and zahary worked on one but both disappeared |
11:26:55 | Araq | they'll come back though |
11:26:57 | BitPuffin | Araq: a component system you say |
11:27:36 | dom96 | Well this works: https://gist.github.com/dom96/aeabe322d4ee42b56d9b |
11:28:43 | Araq | dom96: that's a nice solution |
11:29:40 | BitPuffin | TBleh :D |
11:29:46 | dom96 | :) |
11:32:29 | BitPuffin | dom96: Hmm, so you think I should do when blah != bleh {.fatal.} for example? |
11:32:43 | dom96 | yeah |
11:32:58 | BitPuffin | But hmm |
11:33:04 | BitPuffin | it still can't be known at compile time |
11:33:18 | BitPuffin | maybe it will work though |
11:34:02 | BitPuffin | I'll give it a shot |
11:51:05 | BitPuffin | but child.kind is not known at compile time |
11:51:11 | BitPuffin | we'll see what happens |
11:59:55 | * | Endy quit (Ping timeout: 276 seconds) |
12:16:11 | * | Boscop joined #nimrod |
12:36:23 | * | Endy joined #nimrod |
12:48:42 | dom96 | Aww. I tried connecting 10K clients to my local server and got a 'System error [EOS]'. On the bright side it's the first i've seen this error, so achievement unlocked! :D |
12:53:28 | BitPuffin | dom96: dawh |
13:15:00 | * | DAddYE joined #nimrod |
13:21:40 | * | DAddYE quit (Ping timeout: 268 seconds) |
13:22:39 | NimBot | Araq/Nimrod asyncmacro 725ea68 Dominik Picheta [+2 ±1 -2]: Implemented 'await connect' fully. Fixed a buffering and 'reqReg' bug.... 9 more lines |
13:23:35 | dom96 | whew |
13:23:57 | BitPuffin | woho! |
13:31:44 | * | rubino123 joined #nimrod |
14:00:06 | * | Endy quit (Read error: Operation timed out) |
14:11:54 | * | BitPuffin quit (Ping timeout: 264 seconds) |
14:39:46 | * | Endy joined #nimrod |
15:07:05 | * | ___ joined #nimrod |
15:07:23 | * | ___ quit (Client Quit) |
15:42:30 | * | Endy quit (Ping timeout: 264 seconds) |
16:19:04 | * | DAddYE joined #nimrod |
16:23:49 | * | DAddYE quit (Ping timeout: 276 seconds) |
16:27:39 | * | OrionPK joined #nimrod |
16:29:40 | * | Endy joined #nimrod |
16:31:35 | * | Associat0r joined #nimrod |
16:31:35 | * | Associat0r quit (Changing host) |
16:31:35 | * | Associat0r joined #nimrod |
16:32:18 | * | XAMPP joined #nimrod |
16:43:39 | * | Endy quit (Quit: HydraIRC -> http://www.hydrairc.com <- Nine out of ten l33t h4x0rz prefer it) |
17:06:25 | * | Trix[a]r_za is now known as Trixar_za |
17:14:24 | * | Mat2 joined #nimrod |
17:14:26 | Mat2 | hello |
17:15:25 | dom96 | hey Mat2 |
17:19:46 | * | DAddYE joined #nimrod |
17:25:11 | Mat2 | hi dom96 |
17:26:16 | * | DAddYE quit (Ping timeout: 264 seconds) |
17:34:54 | * | silven quit (Ping timeout: 264 seconds) |
17:40:16 | * | silven joined #nimrod |
17:52:23 | * | rubino123 quit (Ping timeout: 268 seconds) |
18:00:22 | * | Trixar_za is now known as Trix[a]r_za |
18:04:53 | * | rubino123 joined #nimrod |
19:14:06 | dom96 | Mat2: So did you test Aporia on your RPI? |
19:15:56 | NimBot | Araq/Nimrod master 853965f Araq [+0 ±7 -0]: new VM: next steps |
19:17:16 | Mat2 | dom96: no, at moment building a suitable os configuration. After that's finished I can compile the sources (this will take some time, I espect 2-4 hours). I thin somewhere in 4 hours I can tell you the results |
19:17:29 | Mat2 | ^think |
19:17:51 | dom96 | alright. Thanks. |
19:20:53 | * | NewGuy joined #nimrod |
19:21:08 | NewGuy | Howdy, fellas. |
19:21:53 | Mat2 | hi NewGuy |
19:22:27 | dom96 | hello NewGuy :) |
19:22:56 | Mat2 | ehm, what mean fellas ? |
19:23:15 | dom96 | Same as 'guys' |
19:23:24 | Mat2 | ah |
19:24:16 | dom96 | NewGuy: What brings you here? |
19:31:22 | NewGuy | Sorry, about that, back. |
19:32:26 | NewGuy | Anywho - I'm new to Nimrod (thus the name), and I'm going to go grab the compiler now. But I was wondering if you recommend using the 0.9.2 that has the easy installer, or just go ahead and recompile from the git, say, weekly? |
19:33:38 | dom96 | best to get it from git to get all the newest bug fixes and features. |
19:34:02 | dom96 | Pretty much everyone targets the compiler from git, including me. |
19:34:21 | NewGuy | Oh okay, well that answers that! |
19:34:55 | NewGuy | Thanks for the quick reply, Dom. |
19:35:01 | dom96 | np |
19:37:05 | * | Mat2 debian running, next step: configuration, dev -packs installation (+ nimrod, ide) |
19:37:17 | dom96 | :D |
19:44:12 | * | exhu joined #nimrod |
19:45:32 | exhu | hey Araq, what's the intent behind enforcing new code style and case-sensitivity? Is it that many people have whined about pascal-style naming? |
19:47:50 | dom96 | I believe that is it indeed. People are scared by the T/P prefixes. |
19:55:46 | Mat2 | well, I can still not understand the reason for this |
20:01:43 | Mat2 | however, all development dependencies seem to be quite large for this little board. I would prefer crosscompiling for the future |
20:09:17 | Araq | exhu: meh ... actually the new way is pretty much the same as the old way really |
20:09:50 | Mat2 | hi Araq |
20:09:53 | Araq | but I hope it's much better for marketing |
20:10:10 | Araq | however, it breaks pretty much every single line of code |
20:12:58 | Araq | but don't worry |
20:13:32 | Araq | either it stays as it is or we're gonna get close to 100% perfect translation to the new style |
20:17:09 | Araq | exhu: indeed the primary reason is that people consider the prefixes archaic |
20:18:00 | Araq | the problem is that the T/P also really help, so I'm torn |
20:18:14 | exhu | Araq, so should i write my lib and new bindings according to the new style right now? |
20:18:25 | Araq | hell no |
20:19:18 | exhu | but how old code can be run if std lib changes? |
20:19:56 | * | Mat2 now compiling nimrod |
20:20:31 | Araq | ok, I'll reply on the forum ;-) |
20:20:36 | Araq | but here is the short version: |
20:21:16 | Araq | currently Nimrod is SI so it can be translated to any style we pick |
20:21:33 | Araq | this is only a cosmetic change so nothing breaks |
20:22:49 | Araq | after everything adheres to the style, we can make the language full CS or - like I prefer - only CS for the first character which keeps most of the original flexibility but allows 'var a: A' |
20:23:48 | Araq | afterwards we can introduce aliases like 'type TServer {.deprecated.} = Server' and get rid of T/P |
20:24:01 | * | DAddYE joined #nimrod |
20:24:45 | * | NewGuy quit (Ping timeout: 250 seconds) |
20:25:30 | Araq | that said, 'var a: A' already works with the current language so we could also simply decide to ditch T/P for new code |
20:31:04 | * | DAddYE quit (Ping timeout: 264 seconds) |
20:31:20 | Mat2 | dom96: I espect compiling nimrod takes ~2 hours |
20:32:13 | dom96 | Perhaps. The RPI is kinda slow. I don't think it took that long when I compiled it on the RPI though. |
20:33:08 | Mat2 | I hope so :) |
20:33:57 | Araq | exhu: however the proposed style is more frictional wrt the original C names, so I would be interested how it works out for you with X11 and the WinAPI etc. |
20:34:44 | exhu | Araq, i'm afraid it'll be a hell to support bindings if they adhere to the new style |
20:35:54 | Araq | proc FindFirstFileW*(lpFileName: widecstring, |
20:35:55 | Araq | lpFindFileData: var TWIN32_FIND_DATA): THANDLE {. |
20:35:57 | Araq | stdcall, dynlib: "kernel32", importc: "FindFirstFileW".} |
20:36:00 | Araq | vs. |
20:36:34 | Araq | proc findFirstFileW*(lpFileName: Widecstring, |
20:36:35 | Araq | lpFindFileData: var Win32FindData): Handle {. |
20:36:37 | Araq | stdcall, dynlib: "kernel32", importc: "FindFirstFileW".} |
20:38:32 | Araq | years of different programming languages and styles made me dyslexic ... I'm pretty bad at deciding these things :-) |
20:38:57 | exhu | Araq, btw Widecstring or WideCstring ? -) |
20:39:18 | Araq | indeed |
20:39:35 | Araq | and what's worst: you have both and they mean different things |
20:40:15 | exhu | Araq, i prefer to use original style for bindings, because of easy search through files. But not sure if it will be a problem |
20:40:45 | exhu | Araq, also i wonder how GTK bindings will look like -) |
20:40:52 | dom96 | I think it makes sense to go for WideCString in that case. |
20:40:57 | exhu | Araq, c2nim will need conversion too. |
20:41:04 | dom96 | 'C' is separate word in that case |
20:41:20 | exhu | dom96, so goes for TCP -) |
20:41:47 | dom96 | Araq already said that it should be Tcp :P |
20:42:13 | exhu | dom96, sorry, TCP is abbreviation and C is not, my fault |
20:42:23 | dom96 | indeed |
20:42:49 | exhu | GL_STENCIL_BUFFER_BIT -> GlStencilBufferBit ? |
20:43:02 | Araq | of course now we all know WideCstring should be an exported identifier whereas wideCstring is a private one |
20:43:18 | dom96 | Araq: huh? |
20:43:39 | Araq | that's very useful to know because obviously bugs are never in public symbols and private/public is a totally stable criterium ... |
20:43:55 | * | Araq is making fun of Go again |
20:45:44 | dom96 | i see... |
20:46:30 | Araq | exhu: true c2nim needs to know about the One True Style |
20:46:50 | Mat2 | "One True Style" *g* |
20:46:59 | exhu | Araq, it's so much work |
20:47:00 | dom96 | As sanctioned by the BDFL. |
20:50:44 | Araq | exhu: as I said the GL_STENCIL_BUFFER_BIT -> GlStencilBufferBit would be automated |
20:51:27 | Araq | and maybe it should be StencilBufferBit |
20:51:27 | * | Mat2 nimrod compiled without problems, now compiling the IDE |
20:51:58 | dom96 | good, it didn't take 2 hours :) |
20:53:53 | Mat2 | hmm, I think my old 8-bit commodore system compiles faster (LUnix) but however, it works |
20:54:12 | exhu | Araq, on my home LCD GL_STENCIL_BUFFER_BIT is more readable than StencilBufferBit -) |
20:54:47 | exhu | i use small fonts -) |
20:56:31 | Mat2 | (^little joke) |
20:57:20 | Araq | I don't think so, exhu |
20:57:43 | Araq | OTHERWISE_YOU_WOULD_HAVE_CODE_LIKE_THIS_EVERYWHERE |
20:57:52 | Araq | but you don't, only for constants |
20:58:08 | Araq | what you mean it's more readable because you're used to this name |
20:58:55 | exhu | Araq, yes, i got used to it, it's the same for all opengl books for the last ten years :) |
20:59:43 | Araq | yeah so the argument "it doesn't matter there is a rule to translate from the C name to the Nimrod name" is not valid |
21:00:37 | Araq | that's what I feared |
21:01:11 | Araq | so enforcing things to look the same everywhere only works if we don't consider external libraries |
21:01:48 | exhu | Araq, exactly, that's why i feel uncomfortable with the new style enforced on bindings as well. |
21:02:57 | Mat2 | in addition, there exist multible style conventions dependent on the library (and the preferences of there programmers) |
21:03:27 | exhu | Araq, however, given a rule, there will be some time to adopt and then the bindings users/writers will get accustomed to. |
21:04:45 | exhu | Araq, there're already some exceptions in bindings, like functions to access unions or field names which are keywords in nimrod etc. |
21:05:50 | Araq | the Golang OpenGl wrapper uses ALL_CAPS for the constants too |
21:06:21 | Araq | fortunately they are all exported anyway ;-) |
21:06:45 | Araq | it strips the GL_ prefix though |
21:06:56 | Mat2 | *wah* |
21:07:22 | Araq | T = 0x2001 # yeah, nice ... |
21:07:27 | Araq | what's GL_T ? |
21:13:56 | exhu | Araq, GL_T maybe about texture wrapping |
21:14:58 | Araq | or about matrix transpose? |
21:15:57 | * | Mat2 now cloning Aporia |
21:16:21 | exhu | "Here is how to specify texture coordinate generation : |
21:16:21 | exhu | coordinate is the component of the texture coordinate ie GL_R, GL_S, GL_T or GL_Q." |
21:18:09 | * | exhu quit (Quit: Ex-Chat) |
21:18:38 | Araq | I wish people would at least say "bye" |
21:21:51 | dom96 | agreed |
21:30:09 | Mat2 | dom96: compiling Aporia resulting in a SIGSEGV exception, the nimrod compiler itself works fine |
21:31:27 | dom96 | Can you bootstrap in debug mode and show us the traceback? |
21:31:34 | Araq | so the compiler crashes? or aporia at startup? |
21:32:09 | Mat2 | nether the compiler nor aporia but debian is the problem here |
21:32:56 | Mat2 | I think the memory usage is just too high (and this is possibly a bug of the memory-manager) |
21:34:08 | dom96 | create a swap file |
21:34:32 | Mat2 | already done |
21:35:15 | Mat2 | I will try compiling from my external hd |
21:37:03 | * | NewGuy joined #nimrod |
21:37:21 | NewGuy | So I just finished building the compiler from git. |
21:37:55 | NewGuy | When I go about updating it again, what would be the steps? |
21:37:55 | dom96 | cool |
21:37:58 | NewGuy | Should I just rinse and repeat? |
21:38:16 | dom96 | yeah, git pull && ./koch boot |
21:38:41 | NewGuy | Simple and sweet, thanks my friend. |
21:39:31 | Araq | well ... sometimes you have to build from C |
21:39:32 | Mat2 | the exception is caused compiling line 120 of search.nim |
21:42:04 | Araq | Mat2: that doesn't help |
21:44:00 | Mat2 | I stor the traceback |
21:44:04 | Mat2 | ^store |
21:46:33 | Araq | Mat2: what's the CPU of the rasp? |
21:47:53 | Mat2 | an ARMv6 SoC from broadcom (BCM2835) |
21:48:07 | Mat2 | the traceback is quite short: |
21:48:17 | Araq | what does 'nimrod' say? |
21:49:29 | Mat2 | nothing, only one warning about deprecated OSWError and two hints |
21:49:37 | Mat2 | ^OSError |
21:50:00 | Araq | no sorry |
21:50:10 | Araq | Mine says: |
21:50:12 | Araq | Nimrod Compiler Version 0.9.3 (2013-08-01) [Linux: amd64] |
21:50:23 | Araq | what does yours say? |
21:51:30 | dom96 | Mat2: Execute: nimrod -v |
21:51:31 | Mat2 | Version 0.9.3 |
21:51:51 | Araq | gah no |
21:52:06 | Araq | [Linux: amd64] is the interesting part |
21:52:15 | Araq | what CPU does it claim to be on? |
21:52:42 | Mat2 | [linux: arm] |
21:52:59 | Mat2 | (of course, I'm running it on the board) |
21:54:46 | Mat2 | back to the traceback, one moment (I must typing from display): |
21:56:08 | Mat2 | > Program received SIGSEGV, Segmention fault. |
21:56:57 | Mat2 | > 0x0005e920 in typetostring_196020 () |
21:57:22 | Mat2 | have it, its a buffer overflow |
22:06:36 | Mat2 | sadly I can not figure out what's the source of these typetostring function |
22:18:33 | Mat2 | ok, I save a coredump |
22:24:52 | Mat2 | get some sleep, ciao |
22:25:14 | * | Mat2 quit (Quit: Verlassend) |
22:29:08 | * | DAddYE joined #nimrod |
22:34:21 | * | DAddYE quit (Ping timeout: 264 seconds) |
23:02:48 | * | Trix[a]r_za is now known as Trixar_za |
23:22:51 | * | NewGuy quit (Ping timeout: 250 seconds) |
23:28:34 | * | NewGuy joined #nimrod |
23:30:58 | * | DAddYE joined #nimrod |
23:31:36 | NewGuy | Anyone know why Aporia keeps giving me "could not load: libglib-2.0-0.dll."? |
23:32:20 | NewGuy | Compiled it exactly as the git page said, install all dependencies - I have double checked and the GTK bin folder is definitely on the path, and the file exists. |
23:32:46 | NewGuy | (with the correct filename) |
23:37:30 | * | DAddYE quit (Ping timeout: 245 seconds) |
23:39:12 | NewGuy | Ah, yes, and I'm sporting Windows 7. |