00:15:32 | dom96 | good night |
00:15:58 | filwit | night! |
00:17:31 | EfTwelve | i tried googling for this error, but got no luck. "Error: internal error: value expected, but got a type" any hints as to where i can read up on it? |
00:17:55 | fowl | paste the line |
00:19:37 | EfTwelve | https://gist.github.com/anonymous/6337145 |
00:20:18 | EfTwelve | oops.. https://gist.github.com/anonymous/6337147 |
00:20:51 | fowl | var adtw = array[0..LENN,array[0..LENM,float]] |
00:21:09 | fowl | so it expects a value, but array[..., ...] is a type |
00:21:18 | fowl | you want var adtw : array[.., ...] |
00:22:25 | EfTwelve | i see, so arrays must always be declared with 'type'? |
00:22:54 | EfTwelve | but as a function argument they are declared with 'var' ? |
00:23:13 | fowl | EfTwelve, array[1, int] is not a value, its a type |
00:23:43 | fowl | now if you want to do var x = [1] then it has the type array[0..0, int] |
00:23:52 | * | Widdershin joined #nimrod |
00:23:59 | * | BitPuffin quit (Ping timeout: 268 seconds) |
00:23:59 | Widdershin | Hey guys |
00:24:02 | Widdershin | I need some help |
00:24:03 | fowl | hi |
00:24:13 | fowl | shoot, im here for 20 minutes |
00:24:17 | Widdershin | I'm trying out Nimrod, and I'm just trying to make something basic to learn |
00:24:34 | Widdershin | Using httpclient.getContent, how do I make a call through a proxy? |
00:24:53 | Widdershin | All I'm trying to do is get the content of a web page, but I'm behind a proxy |
00:25:21 | Widdershin | It doesn't require any credentials, for the record, but requests still need to go through it |
00:25:28 | * | freefall left #nimrod (#nimrod) |
00:25:29 | * | filwit quit (Quit: Leaving) |
00:25:51 | Araq | hi Widdershin, welcome |
00:25:56 | Widdershin | Gidday Araq |
00:26:14 | Araq | I can't answer your question unfortunately; dom96 can do that be is sleeping |
00:26:22 | Araq | *but he is |
00:26:28 | dom96 | Lucky for you I am still here. |
00:26:39 | fowl | EfTwelve, do you get it |
00:26:48 | dom96 | :P |
00:26:53 | Widdershin | Any thoughts dom96? |
00:27:16 | dom96 | sec, researching this :P |
00:27:19 | EfTwelve | ya, makes sense. thanks! |
00:27:27 | Araq | alright then I will sleep. bye |
00:29:45 | EfTwelve | g'night |
00:34:52 | dom96 | Widdershin: Sadly, the httpclient module currently doesn't support this :( |
00:35:12 | Widdershin | dom96: Should I open an issue? |
00:36:29 | dom96 | I'll try to implement this now for you but I can't promise anything. |
00:37:32 | Widdershin | Cheers man |
00:37:36 | Widdershin | I can always work around it |
00:39:11 | dom96 | Alright. I may as well try it though since it doesn't seem too complicated. |
00:39:15 | Widdershin | dom96: Are you the dev for Nimrod? |
00:40:00 | dom96 | Widdershin: I'm one of the main contributor's and I wrote a lot of the standard library. But Araq is the main guy behind Nimrod. |
00:40:12 | Widdershin | Ah cool |
00:49:41 | dom96 | nah, sorry. There is authorization to think about and probably other little things. I don't want to have to change the interface later, and also 2am is too late to be implementing these things heh. |
00:49:59 | dom96 | I'll implement it for you tomorrow if you'd like. |
00:50:07 | dom96 | What are you writing? |
00:50:19 | dom96 | (if you don't mind saying) |
00:50:42 | Widdershin | dom96: My work has an internal betting app for sports |
00:50:53 | Widdershin | And I'm doing well this season so far |
00:50:56 | Widdershin | out of pure luck |
00:51:04 | Widdershin | So I decided to make something to scrape scores and give odds |
00:51:11 | Widdershin | And I thought I would try something in nimrod |
00:51:25 | dom96 | oh. Well sorry about this. |
00:51:54 | dom96 | I would implement this for you but it's quite late for me. |
00:52:07 | Widdershin | Don't worry about it dom96 |
00:52:33 | Widdershin | I'll just bang out a python script that takes urls and a proxy and returns the html |
00:53:34 | * | fowl quit (Quit: Leaving) |
00:53:51 | dom96 | Alright. Hopefully you'll be able to find another use for Nimrod. |
00:54:10 | Widdershin | I'll still write the rest of it |
00:54:14 | Widdershin | In nimrod |
00:54:24 | dom96 | oh cool. |
00:54:27 | Widdershin | I'll just outsource the web page request to python |
00:54:54 | dom96 | ok. Have fun. Good night. |
00:55:04 | Widdershin | Sleep well mate |
01:30:31 | * | q66 quit (Quit: Leaving) |
02:59:26 | * | darithorn joined #nimrod |
03:45:57 | shodan45 | tiny nitpick: how come there's no tar.gz (or .bz2, etc) for the source download? |
04:05:39 | Trixar_za | Because most systems supports or comes with unzip? |
04:08:12 | * | OrionPK quit (Read error: Connection reset by peer) |
04:10:41 | shodan45 | Trixar_za: and most open source projects come with tar files ;) |
04:12:35 | Trixar_za | Not if they include a Windows or Mac build. The default seems to be zip for both |
04:13:01 | Trixar_za | Also it defaults to zip files on github too :P |
04:18:51 | shodan45 | Trixar_za: hm? windows or mac build? what project supports windows, mac, *nix, and doesn't have source available in a tar file? |
04:19:34 | Trixar_za | Off the top of my head, I would say renpy |
04:20:05 | Trixar_za | But it does have source in tar.bz2 avaliable, but the windows and mac builds are zip files |
04:20:49 | Trixar_za | Mind you, I remember a time that only tar.gz was standard for most files. Now we're moving towards tar.xz |
04:21:14 | Trixar_za | zip atleast seems like a constant |
04:23:18 | shodan45 | Trixar_za: well sure a windows build comes in a zip... I'm just saying that source files are typically available in (at least) a .tar.gz for cross platform projects |
04:27:51 | Trixar_za | Could also be for convience. It's easier to remember unzip file.zip than tar zxf file.tar.gz or tar xfj file.tar.bz2 - and that's if you don't use bunzip or gunzip to extract them, then it needs to be tar xf file.tar |
04:29:50 | * | xilo quit (Read error: Operation timed out) |
04:47:16 | shodan45 | Trixar_za: or you could use a GUI ;p |
04:47:44 | Trixar_za | Yeah, but they sometimes mess up symlinks and permissions :P |
04:48:02 | Trixar_za | Not that zip doesn't do that anyway, but yeah |
04:49:49 | shodan45 | hm, I don't remember any problems like that |
04:50:38 | shodan45 | heh, anyway, like I said - tiny nitpick |
04:52:31 | shodan45 | Trixar_za: and not sure when this was changed/added, but tar (gnu tar, anyway) "x" auto detects compression type |
04:53:36 | Trixar_za | Really? Would have helped if I knew it sooner :P |
05:07:15 | * | darithorn_ joined #nimrod |
05:10:18 | * | darithorn quit (Ping timeout: 264 seconds) |
05:26:04 | * | brson quit (Quit: leaving) |
05:27:06 | * | Associat0r quit (Quit: Associat0r) |
06:25:06 | comex | you're famous |
06:50:55 | * | Endeg joined #nimrod |
07:23:49 | EfTwelve | why would i get the error 'type expected' when assigning a float to a float array? |
07:24:12 | * | ponce joined #nimrod |
07:52:56 | EfTwelve | anyone? |
08:19:57 | vegai | can you paste the code |
08:24:52 | EfTwelve | https://gist.github.com/anonymous/6339186 |
08:33:23 | vegai | hmm, is adtw a type? |
08:34:24 | vegai | doesn't seem to matter... |
08:36:34 | EfTwelve | i was told earlier that an array cant be declared with 'var' |
08:36:35 | vegai | I guess you need to first declare it as a type like you did |
08:36:47 | EfTwelve | although the docs show that in a few places |
08:36:50 | vegai | then declare your variable of that type |
08:37:01 | vegai | i.e. |
08:37:02 | vegai | type adtwType = array[0..LENN, array[0..LENM,float]] |
08:37:09 | vegai | var adtw : adtwType |
08:37:14 | vegai | with better indentation |
08:37:28 | vegai | like they do here: http://nimrod-code.org/tut1.html#arrays |
08:38:03 | EfTwelve | thats seems to work. |
08:38:07 | darithorn_ | I'm able to create arrays using 'var' |
08:38:26 | EfTwelve | but i gotta say that is a terrible to do it. |
08:38:31 | darithorn_ | var myArray = [1, 2, 3, 4] |
08:38:36 | EfTwelve | via type that is |
08:38:53 | EfTwelve | what if your array is 100 elements? |
08:39:29 | darithorn_ | var myArray: array[0..99, int] |
08:41:19 | EfTwelve | hmm, that declaration works, but cant assign to it |
08:41:44 | vegai | EfTwelve: you mean doing the type + var thing is a terrible way? |
08:42:51 | EfTwelve | yes, trashing up the namespace with type declarations everytime you want an array seems really bad. I hope im misunderstanding 'cause im new. |
08:44:06 | * | EXetoC joined #nimrod |
08:49:14 | vegai | well... seems like it's just a local namespace of the function |
08:49:24 | vegai | have you considered sequences? |
08:50:29 | EfTwelve | the docs only show them assigned with literals -> @[1,2,3] |
08:50:37 | EfTwelve | thats all i have to go on. |
08:51:00 | * | q66 joined #nimrod |
08:53:08 | EfTwelve | they are declared empty, no info on how to append or resize, no info on them at all really. :( |
08:53:24 | vegai | hmm, they say that seqs are dynamic in length, but I'm able to crash the interpreter by just adding to a seq's size+1 |
08:57:07 | EXetoC | you're calling setLen? I think you need to initialize with newSeq. these functions are documented in the generated documentation for system.nim |
08:58:08 | vegai | yep, setLen works. So it's not automatically dynamic |
08:58:14 | vegai | just resizeable |
08:58:48 | EXetoC | it is dynamic. the capacity can't be set by users though |
09:00:46 | * | zahary_ joined #nimrod |
09:05:34 | EfTwelve | so it takes 3 statements to make a sequence. |
09:06:37 | EXetoC | I think two is enough, but that'll soon be reduced to either a minimum of one or zero |
09:07:00 | EfTwelve | i tried making a proc that takes a length and returns a new seq, but that fails too |
09:08:31 | EXetoC | you can just call newSeq[Type](length), and length can be omitted for this overload, in which case it'll be zero |
09:11:22 | EfTwelve | oh.. that works. nice! |
09:13:38 | EXetoC | "var stuff = newSeq[int](42)" and also "var stuff: seq[int]; newSeq(stuff, 42)", and for this overload, the length parameter isn't optional, which you can see if you browse the documentation (again for system.nim, where much of the core language is defined) |
09:16:11 | EXetoC | and then there's 'add' for appending. the '&=' operator does the same thing, but it currently only exists for strings. you can still append with '&' though (stuff = stuff & 42) |
09:17:37 | vegai | it would be useful to augment the tutorial's seq section to include those things |
09:18:37 | EfTwelve | thats much easier to deal with. thanks |
09:18:54 | EfTwelve | i agree, the tuts page could some of that info. |
09:18:55 | EXetoC | vegai: yeah |
09:21:30 | EfTwelve | its crazy late, gotta go to sleep, |
09:21:36 | EfTwelve | thanks for all the help! |
09:21:51 | EXetoC | crap timezone :> |
09:21:55 | EXetoC | np. later! |
09:23:08 | EXetoC | by the way, you can omit newSeq if you don't need to pre-allocate, by appending using 'safeAdd', but I think 'add', '&=' and '&' will be safe by default in the future |
09:24:04 | EXetoC | that's almost set in stone I think, so that'll simplify things |
09:25:24 | EXetoC | and the current 'add' would just be 'unsafeAdd' or something, which wouldn't initialize the input sequence if nil (for optimization purposes) |
09:54:56 | vegai | I wonder if I'd be able to find the repo where that tutorial is |
10:22:01 | * | BitPuffin joined #nimrod |
10:30:23 | * | darithorn_ quit (Quit: Leaving) |
11:08:50 | * | jbe_ joined #nimrod |
11:12:48 | xyproto | dom96: hi, sorry for the late answer, but yes, it means that TUs and/or devs will be responsible for updating the nimrod package for now. So, unless upstream goes completely silent for a long while, it will be taken good care of. :) |
11:26:51 | dom96 | xyproto: hi, no worries. Thanks for the answer :) |
11:29:33 | nihathrael | was nimrod moved to community? |
11:29:42 | dom96 | indeed it was |
11:29:50 | nihathrael | nice, great step forward |
11:31:42 | dom96 | hah, I knew someone would submit it to proggit too heh. |
11:41:20 | EXetoC | vegai: did you find it? I wish I could help out in some way. maybe I'll have some time later |
11:42:33 | dom96 | vegai: The tutorial (including other docs) are here: https://github.com/Araq/Nimrod/tree/master/doc |
11:43:07 | EXetoC | is it mostly the stuff in the 2nd tutorial that's already in the manual? |
11:46:49 | dom96 | The manual is a full spec of the language, so the tutorial is just a more beginner friendly explanation of the stuff in the manual. |
11:47:29 | * | Associat0r joined #nimrod |
11:47:29 | * | Associat0r quit (Changing host) |
11:47:29 | * | Associat0r joined #nimrod |
12:20:58 | * | faassen joined #nimrod |
12:21:11 | faassen | hey. |
12:21:17 | dom96 | hello faassen |
12:21:36 | faassen | been reading about Nimrod this weekend, now there's a reddit discussion, have you guys seen it? |
12:22:10 | dom96 | Yep. You're defending Nimrod very well, thanks :) |
12:22:27 | faassen | heh, I'm just reporting on what I read in the docs. |
12:23:32 | faassen | of course I liked what I read in the docs or I wouldn't have kept reading. |
12:23:35 | faassen | have you guys heard of Lobster? |
12:24:03 | oal | yes, the game programming language thing? |
12:24:19 | faassen | yes, it has some interesting parallel evolution in the language. |
12:24:27 | faassen | at least I assume there was no direct mutual influence. |
12:25:04 | faassen | heh, and its community support is not so good, its wiki currently down. :) |
12:25:40 | faassen | but it has multiple dispatch and it has an interesting approach to designing new statements (as functions) that's a bit like Nimrod's template system. |
12:25:46 | dom96 | oh yes, I heard of it. This Minecraft clone really impressed me: http://i.imgur.com/ZZWFkXn.jpg |
12:26:21 | faassen | I couldn't get lobster's GL support to work on my system, I'm sure it's something I'm doing wrong with the SDL 2 thing. |
12:26:36 | dom96 | However I like my software compiled and Lobster is interpreted IIRC |
12:27:05 | faassen | I don't mind interpretation, but for a gamey/simulation target domain Nimrod's compilation is nice. |
12:27:46 | faassen | (I'm a long time Python user) |
12:28:33 | dom96 | I was a python user too, the reason I left it was because I wanted something compiled heh |
12:29:43 | faassen | I left C++ for Python long ago and quickly got over my need to have stuff compiled. But I do like performance and while I'm ambivalent about static type systems, I can't say they don't have their advantages. :) |
12:31:35 | faassen | anyway, I like Nimrod's design choices, very nice. |
12:31:50 | faassen | it's been flying under the radar for years, hasn't it? |
12:32:59 | EXetoC | I care more about what the type system is like, rather than how the execution is done |
12:35:35 | oal | I spent some time learning Julia a few weekends ago. I ported some Go code I'd written. One of the programs ran 20% faster, the other one about 30% slower. |
12:35:51 | oal | It's dynamic with optional static typing, and JITed |
12:36:13 | oal | Memory usage was quite high, and it's pretty unstable yet, but I think it has potential |
12:37:12 | oal | Then I found nimrod this weekend, but haven't had time to do more than reading the tutorials |
12:37:26 | faassen | oh, yeah, I saw Julia too, though I didn't delve into it yet. |
12:38:15 | faassen | it's interesting how many languages with Python-style syntax are emerging these days. (for a flexible interpretation of "emerging") |
12:38:21 | oal | It looks very good so far though. I'm coming from Python myself, and while Go is a neat language, I prefer a Pythonic syntax, and Go doesn't have generics etc |
12:39:13 | oal | The concurrency features in Go is really convenient though :) |
12:44:59 | EXetoC | some people complain about the fact that others expect every language to have generics |
12:47:16 | reactormonk | EXetoC, any other way to type lists? |
12:47:34 | faassen | well, a dynamically typed language doesn't need generics. :) |
12:47:39 | * | OrionPK joined #nimrod |
12:47:49 | oal | Also, the type embedding in Go is a little bit annoying at times. If I have a type A that embeds B, then do myA.bFunction().aFunction(), that won't work because bFunction would have to return B, and A's methods wouldn't be available. So no method chaining without very strict limitations :( |
12:47:53 | reactormonk | we're talking about static typing here. |
12:48:11 | faassen | reactormonk: I know, that's why my statement was cheeky. :) |
12:49:32 | EXetoC | reactormonk: I don't know |
12:49:35 | Associat0r | a typed language without generics is broken |
12:49:53 | reactormonk | or C. |
12:50:10 | oal | Or at least multiple dispatch |
12:50:56 | EXetoC | I rarely use multiple dispatch nowadays |
12:53:41 | * | Associat0r quit (Quit: Associat0r) |
13:01:27 | EXetoC | but maybe it's more useful when implementing types that you expect third-party sources to extend, but I guess you can deal with that in multiple ways, especially in expressive languages |
13:09:17 | faassen | I use something like multiple dispatch in Python where I want to extend third-party classes without changing them, in the context of model/view in web dev. i.e. you look up a view based on a model class and a request class. |
13:13:37 | EXetoC | dom96: you said you didn't see the need for inheritance IIRC, so would you take a different approach compared to GTK (which is built on such concepts), had you been designing your own widget toolkit? in whatever language |
13:13:55 | EXetoC | faassen: yeah it's trivial in such language. I wish duck-typing was opt-in though |
13:14:59 | faassen | EXetoC: actually in Python doing the correct lookup based on multiple dispatch isn't totally trivial in my experience, but I may be missing something. |
13:15:51 | dom96 | EXetoC: That's not my opinion. I only ever said that I never had the need to use methods in Nimrod. |
13:25:25 | EXetoC | ok |
13:25:52 | * | io2 joined #nimrod |
13:32:10 | * | circ-user-xAMIG joined #nimrod |
13:33:45 | dom96 | Wow, there is a very large amount of comments in the nimrod thread downvoted below the 'visibility threshold'. |
13:35:00 | * | circ-user-xAMIG left #nimrod (#nimrod) |
13:35:19 | EXetoC | link? I lost it |
13:35:33 | dom96 | http://www.reddit.com/r/programming/comments/1l3p2j/nimrod_c_macros_gc/ |
13:35:49 | * | circ-user-xAMIG joined #nimrod |
13:36:48 | * | open-source joined #nimrod |
13:37:45 | EXetoC | "You use C to be in control of everything and then you put a GC on it, who breaks your program flow at random?" I guess some languages don't allow users to either disable or remove the GC altogether |
13:38:11 | OrionPK | he had one decent point |
13:38:31 | OrionPK | if you're relying on someone else's library who is relying on the GC and you disable it, could be trouble |
13:39:48 | dom96 | Yeah, when I read that I immediately thought that Nimrod's effect system would nicely make this safer. You could add a 'FGC' effect to any functions which rely on the GC. |
13:40:06 | open-source | quit |
13:40:14 | OrionPK | yeah |
13:40:14 | * | open-source quit (Client Quit) |
13:40:27 | OrionPK | would be nice to have more granular control on that dom96 |
13:41:33 | dom96 | I think the effect system is still not finished. |
13:42:54 | EXetoC | you'd pre-allocate in many types of applications though, and that's even less of an issue if there's a real-time GC |
13:43:38 | EXetoC | I disliked the whole concept of garbage collection even before I knew what it was, because I assumed that most people's opinions were educated, but that's often not the case :> |
14:04:11 | * | EXetoC is now known as EXetoC_ |
14:04:31 | EXetoC_ | dom96: how's the async stuff coming along? |
14:05:02 | dom96 | Not working on it currently. |
14:06:12 | profmakx | m( |
14:07:59 | EXetoC_ | just make sure that it's usable some time before 1.0 :> |
14:09:40 | EXetoC_ | only ~15 months to go! |
14:09:41 | EXetoC_ | later |
14:10:01 | faassen | OrionPK: I agree that was a decent point. |
14:53:20 | * | Sphax joined #nimrod |
14:53:42 | dom96 | hello Sphax |
14:53:53 | Sphax | Hi |
14:59:02 | shodan45 | is there a nimrod REPL or interpreter? |
14:59:26 | faassen | shodan45: I saw a reference to it being worked on so that means no there isn't. :) |
14:59:38 | dom96 | There is: nimrod i |
14:59:43 | dom96 | But it's quite limited. |
14:59:54 | faassen | ah, sorry, I am wrong! |
15:01:18 | shodan45 | dom96: interesting! helps to rtfm it seems :) |
15:02:03 | dom96 | I don't mind answering questions :) |
15:02:57 | shodan45 | dom96: how is this accomplished? some kind of compile as-you-go, or a whole separate interpreter? |
15:03:49 | faassen | shodan45: my reading (which might be wrong :) indicated that they were trying to generate an interpreter from the compiler's tracing mechanism or something like that. |
15:04:04 | faassen | dom96: am I wrong again? :) |
15:04:08 | dom96 | shodan45: The compiler already needs to evaluate Nimrod code for compile-time procs and macros so it's basically that. |
15:04:23 | faassen | okay I'm sorta right. |
15:04:57 | dom96 | Araq is working on a new virtual machine for this which will make things faster and allow for FFI in the REPL (which I desperately want :P) |
15:05:01 | shodan45 | dom96: wow, ok... seems I haven't read that part of the tutorial yet |
15:05:24 | dom96 | I don't think the tutorial mentions it. |
15:05:29 | shodan45 | ah :) |
15:05:39 | faassen | the nimrod docs refer to 'deferrent reference counting' but a google for that turns up 'deferred reference counting' and a strict google only seems to turn up nimrod docs. |
15:05:48 | faassen | is this a typo in the gc doc? |
15:06:15 | shodan45 | hehe... there going to be an eval()? |
15:06:24 | * | shodan45 smirks evilly |
15:06:49 | dom96 | shodan45: yep |
15:07:24 | dom96 | faassen: Quite possible. |
15:07:26 | Araq | faassen: ugh typo indeed |
15:08:59 | * | silven quit (Remote host closed the connection) |
15:09:16 | faassen | Araq: hey! nice language! |
15:12:24 | faassen | anyway, off now, see you later. :) |
15:12:32 | Araq | thank you |
15:13:12 | * | faassen quit (Remote host closed the connection) |
15:24:59 | shodan45 | *ahem* how do you quit from "nimrod i"? |
15:25:27 | Araq | quit() |
15:25:37 | shodan45 | Araq: ty :) |
15:30:01 | circ-user-xAMIG | for js target, do we have a tutorial on how to call native js function? i guess it requires a wrapper. if this is the case, do we have or plan to write a tool like we had for c2nim? |
15:37:15 | Araq | there is an example somewhere, the wrapping happens via the same "importc" etc pragmas |
15:39:05 | Araq | bbl |
15:40:43 | * | zahary_ quit (Ping timeout: 264 seconds) |
16:26:51 | * | Sphax quit (Quit: Page closed) |
16:28:09 | * | Mat2 joined #nimrod |
16:28:12 | Mat2 | hi all |
16:29:44 | * | zahary joined #nimrod |
16:34:22 | dom96 | hi Mat2 |
16:34:45 | Mat2 | hi Mat2 |
16:34:50 | Mat2 | what's new ? |
16:38:09 | Mat2 | I have a lot of fun implementing wild optimizations, the common world do not even know about 8-D |
16:38:17 | Mat2 | soryy hi dom96 |
16:38:23 | dom96 | hehe. |
16:38:30 | dom96 | not much |
16:38:36 | dom96 | Implementing proxy support for the httpclient |
16:39:48 | Mat2 | do you plan writing a web browser ? |
16:40:07 | dom96 | no, this is for Nimrod's stdlib |
16:40:17 | Mat2 | ah ok |
16:41:40 | Mat2 | seems like http services are common usage these days |
16:45:55 | * | Associat0r joined #nimrod |
16:45:55 | * | Associat0r quit (Changing host) |
16:45:55 | * | Associat0r joined #nimrod |
16:50:56 | * | ltbarcly joined #nimrod |
17:02:59 | NimBot | Araq/Nimrod master 0251d3a Dominik Picheta [+0 ±1 -0]: Implemented ability to connect through proxies for the httpclient module. |
17:03:10 | dom96 | Widdershin: Let me know if that works for you. |
17:12:29 | * | joysapsi joined #nimrod |
17:12:40 | Araq | hi joysapsi, welcome |
17:13:16 | joysapsi | hello, could someone point me to the source of the bin/nimrod? In particular i want to see how nimrod i (interactive) is implemented? |
17:13:38 | joysapsi | Araq: hello to you too |
17:15:27 | Mat2 | hi Araq and joysapsi |
17:24:12 | * | Sphax joined #nimrod |
17:24:47 | * | sphax_ joined #nimrod |
17:24:50 | * | Sphax left #nimrod (#nimrod) |
17:25:01 | * | sphax_ quit (Client Quit) |
17:25:28 | * | ltbarcly quit (Read error: Connection reset by peer) |
17:25:39 | * | Sphax joined #nimrod |
17:25:51 | * | brson joined #nimrod |
17:26:23 | * | ltbarcly joined #nimrod |
17:29:11 | Araq | joysapsi: compiler/main.nim does the glueing, the interpreter is in compiler/evals.nim |
17:29:36 | joysapsi | Araq, thanks |
17:31:45 | Araq | but it's about to be replaced with compiler/vm.nim |
17:34:43 | Mat2 | exist the a constant signaling the endianess in Nimrod ? |
17:35:40 | Araq | Mat2: http://nimrod-code.org/system.html#397 |
17:35:58 | Araq | search http://nimrod-code.org/theindex.html for "endian" to find it |
17:36:17 | Mat2 | nice !, thanks |
17:50:01 | Araq | so ltbarcly; how's progress on fixing the object constructor bug? |
17:51:09 | * | Mat2 implementing horizontal sheduling for in-order optimization |
17:52:23 | * | Araq thinks that nobody knows what "horizontal scheduling" means ... |
17:53:29 | Mat2 | pllab.cs.nthu.edu.tw/~jklee/papers/p252-lee.pdf |
17:56:24 | * | nebiros joined #nimrod |
17:56:36 | Araq | hi nebiros, welcome |
17:56:44 | nebiros | Araq: \o, hi |
18:11:57 | Mat2 | hi nebiros |
18:22:57 | dom96 | yo nebiros |
18:28:38 | nebiros | hey guys, any examples about nimrod and cocoa? |
18:36:28 | * | circ-user-xAMIG quit (Remote host closed the connection) |
19:08:05 | Araq | nebiros: ask gradha when he's around |
19:08:27 | nebiros | Araq: I was looking at hist project example on github, yes |
19:09:29 | Araq | yeah |
19:37:11 | * | circ-user-xZoZx joined #nimrod |
19:42:57 | * | XAMPP quit (Quit: Drink all the Booze; Hack all the Things; Kill all the Humans;) |
19:43:03 | * | darithorn joined #nimrod |
19:45:07 | darithorn | does anyone have experience with the nimrod opengl wrapper? |
19:58:00 | Araq | darithorn: BitPuffin and EXetoC_ have I think |
20:02:56 | EXetoC_ | yeah. what do you want to know? All I do is call loadExtensions |
20:03:02 | * | EXetoC_ is now known as EXetoC |
20:03:13 | darithorn | Yeah, I have a triangle being draw. Thing is, it's rotated 90 degrees |
20:03:37 | darithorn | I know it's not my vertex positions because I'm using the same exact positions when I did it in C++, which worked fine |
20:04:37 | Mat2 | hi EXetoC |
20:04:45 | EXetoC | hi |
20:06:03 | EXetoC | I always run into some issues initially, because of incorrect pointer arithmetic |
20:06:28 | BitPuffin | woop |
20:06:42 | Mat2 | hi BitPuffin |
20:06:44 | reactormonk | woop woop |
20:06:57 | BitPuffin | howdy Mat2 |
20:13:26 | * | guaqua joined #nimrod |
20:14:21 | Araq | hi guaqua, welcome |
20:18:05 | darithorn | Ah, I solved it. It's because float != float32 and GLfloat is a float32 |
20:20:49 | guaqua | nimrod seems very interesting! |
20:21:03 | guaqua | combining things from c to common lisp |
20:21:36 | Mat2 | hi uaqua |
20:21:42 | OrionPK | people are comparing nimrod to javascript in that thread, eesh |
20:21:48 | Mat2 | ehm, which things from C do you mean ? |
20:22:02 | Mat2 | hi OrionPK |
20:22:03 | reactormonk | Mat2, speed |
20:22:07 | OrionPK | hola mat2 |
20:22:12 | Mat2 | ah, ok |
20:22:21 | guaqua | well, i guess not the language that much, but the fact that its compiled and produces small binaries :) |
20:22:41 | guaqua | so should i say "shipping mechanism" |
20:22:56 | OrionPK | also that it's ABI compatible with C, since it's compiled through C |
20:22:59 | guaqua | since there's no virtual machine to speak of |
20:27:28 | * | circ-user-xZoZx quit (Remote host closed the connection) |
20:28:20 | Mat2 | well virtual-machines can be of advantage for compilation (a statement which is restricted to efficient VM designs) |
21:10:31 | * | gradha joined #nimrod |
21:12:22 | gradha | darithorn: no real cocoa examples using nimrod yet |
21:12:49 | Mat2 | hi gradha |
21:12:54 | gradha | hi Mat2 |
21:15:35 | gradha | dom96: are you here for the party? |
21:15:45 | dom96 | I'm always here |
21:16:17 | gradha | look how far we are from 50 people |
21:16:43 | dom96 | I'm not going to get excited anymore because I fear I will be disappointed, or that I will jinx it :P |
21:17:39 | gradha | I still believe Aporia has a good use for ouroboros, despite gtk being useless |
21:17:56 | gradha | you could bundle the nimrod compiler with aporia (and the nimrod compiler bundled with the stdlib) |
21:18:16 | gradha | "you dawg, I heard you like compiling, so we put a compiler inside your editor so you can compile while you edit" |
21:18:45 | gradha | you would still need to extract it to /tmp, but it looks promising, the whole IDE+compiler in a single binary |
21:19:37 | gradha | then, since you already have nimrod, you could run "nimrod doc" on itself, and get a local jester webserver with the embedded docs for all stdlib |
21:19:39 | dom96 | can't I just import the compiler in aporia? :P |
21:20:12 | gradha | no idea, can you? still haven't looked much at it |
21:20:37 | * | dom96 considers submitting Nimrod to slashdot |
21:20:49 | gradha | not enough memes, yet |
21:25:12 | gradha | using jester in the nimrod compiler for a "nimrod docserve" command might be cool too |
21:25:28 | BitPuffin | so is nimrod in community now? |
21:25:32 | BitPuffin | in arch? |
21:25:39 | dom96 | yep |
21:25:43 | BitPuffin | cool! |
21:25:49 | BitPuffin | too bad the latest stable release is too old lol |
21:26:03 | BitPuffin | I am going back to arch |
21:26:52 | BitPuffin | getting fglrx working on a legacy card was too hard in crux >.< |
21:27:19 | * | gradha wonders if BitPuffin is missing some vowels on the keyboard |
21:27:38 | BitPuffin | gradha: ? |
21:27:53 | gradha | fglrx sounds a nightmare to say aloud |
21:28:01 | BitPuffin | gradha: blame ATI/AMD |
21:28:33 | BitPuffin | gradha: fire gl radeon x or something is what you could say in real life |
21:28:58 | gradha | according to google I would have named it "propietary-ati-linux-driver", but what do I know about marketing |
21:29:08 | EXetoC | what made you try crux? |
21:29:34 | EXetoC | seems to be similar in some ways |
21:29:51 | BitPuffin | EXetoC: first trying ElementaryOS getting crappy video performance (which wasn't their fault). And I have looked at crux before but then I wasn't good enough at lunix |
21:30:02 | BitPuffin | I wanted a minimal system |
21:30:10 | BitPuffin | crux is even faster than arch |
21:30:19 | BitPuffin | but alas |
21:30:29 | BitPuffin | the proprietary ati driver was just too much |
21:30:31 | EXetoC | broad claim, but ok |
21:30:51 | BitPuffin | EXetoC: well the base systems |
21:30:54 | Mat2 | BitPuffin: Then try Gentoo Linux or the 3 BSD's |
21:31:21 | BitPuffin | EXetoC: I don't mean like CRUX WITH i3 IS FASTER THAN ARCH WITH FULL KDE DESKTOP |
21:31:40 | BitPuffin | Mat2: I would love to use freebsd, but fglrx doesn't even exist for it |
21:32:38 | BitPuffin | Mat2: maybe gentoo one day |
21:32:49 | Mat2 | even with the linux-compatibly module loaded = |
21:32:52 | Mat2 | ? |
21:33:17 | BitPuffin | Mat2: well then maybe it would work, but I doubt it would be easier to get it working in freebsd than in crux |
21:33:41 | BitPuffin | it wouldn't be hard if it wasn't that you have to downgrade x11, apply a bunch of patches to fglrx and do a bunch of shit |
21:33:47 | BitPuffin | I was very close in crux |
21:34:04 | BitPuffin | I could probably just do a little bit more work and having it running |
21:34:13 | BitPuffin | but I dunno, it is easy in arch |
21:35:04 | Mat2 | my experience that small and optimizated xNix systems need work and passion |
21:35:08 | Mat2 | ^is |
21:35:36 | Mat2 | anyhow |
21:36:29 | gradha | Mat2: I still don't understand half of the stuff you do, do you have a blog which explains some of it? or maybe a newsletter? |
21:38:02 | Mat2 | no, I write on a documentation which explains all details |
21:38:32 | Mat2 | and next week I should have a blog |
21:38:44 | BitPuffin | Mat2: yeah that is true |
21:38:51 | gradha | yay! are you a new ipsumgenerawhatever too? |
21:38:55 | BitPuffin | Mat2: I might go back to crux when I have newer hardware |
21:40:03 | Mat2 | gradha: sorry, what do you mean with these statement ? |
21:40:19 | gradha | dom96 recently wrote https://github.com/dom96/ipsumgenera for blog publishing in nimrod |
21:40:41 | gradha | maybe ipsumgenera users are iusers... |
21:40:59 | Mat2 | looks nice, I try it out |
21:41:14 | BitPuffin | is dom96 here? |
21:41:25 | dom96 | yes |
21:41:28 | gradha | BitPuffin: he is always here |
21:41:39 | BitPuffin | hoho |
21:41:43 | BitPuffin | I knew it |
21:41:54 | gradha | dom96: you forgot to announce ipsumgenera in the nimrod forums |
21:42:18 | dom96 | I don't consider it good enough for that yet :P |
21:42:52 | Mat2 | bythe way, what are iusers (users of recent Apple products) ? If so, I am not an iuser |
21:43:09 | gradha | Mat2: that was a joke about ipsumgenera users i-users |
21:43:22 | gradha | dom96: if you don't ask people to try it you won't get much comments on it |
21:43:25 | BitPuffin | dom96: is your blog up yet? I want to see ipsumgenera in action |
21:43:30 | Mat2 | ah ok |
21:43:33 | gradha | BitPuffin: it's even pretty |
21:43:38 | dom96 | BitPuffin: http://picheta.me |
21:45:21 | BitPuffin | dom96: pretty nice design I gotta say :) |
21:45:30 | dom96 | thanks :) |
21:46:58 | Mat2 | looks nice indeed |
21:47:16 | BitPuffin | dom96: hosted on github I presume? |
21:47:28 | dom96 | nope |
21:48:07 | BitPuffin | dom96: NEWP? |
21:48:17 | dom96 | ? |
21:48:29 | Mat2 | BitPuffin: Just read Chris Gilbert has ported fglrx to FreeBSD somewhere 2005 |
21:48:46 | BitPuffin | Mat2: linkur? |
21:48:50 | BitPuffin | dom96: nope? |
21:48:54 | BitPuffin | where do ya håst it |
21:49:56 | Mat2 | http://forums.pcbsd.org/showthread.php?t=2979 |
21:51:14 | BitPuffin | cool |
21:51:19 | BitPuffin | but it's probably very old |
21:51:29 | Mat2 | indeed |
21:51:38 | BitPuffin | anyways |
21:51:43 | * | joysapsi quit (Quit: Page closed) |
21:51:43 | BitPuffin | I am gonna run a very slim arch |
21:52:40 | dom96 | BitPuffin: Linode VPS |
21:52:55 | BitPuffin | dom96: sweet! |
21:53:09 | BitPuffin | dom96: so you trust linode after the breach? |
21:53:40 | dom96 | Not really, but i'm too lazy to switch :P |
21:53:54 | BitPuffin | haha! |
21:53:58 | BitPuffin | Switch to freebsd ;) |
21:55:05 | BitPuffin | Araq: new stable release coming soon? |
21:55:27 | EXetoC | don't disturb him |
21:55:57 | BitPuffin | Araq: I mean we have pretty proper generics now thanks to zahary, so if we patch up most of the known bugs it would be nice. Especially now that nimrod is in community and has a rush of new users |
21:56:04 | BitPuffin | EXetoC: what's he up to? |
21:57:16 | Araq | BitPuffin: tested zahary's new stuff? |
21:57:43 | BitPuffin | Araq: not yet, I have been wrestling with crux, but now that I'll be back on arch soon I'll test it almost immediately! |
21:58:26 | zahary | the compiler support for swizzle is coming soon too |
21:58:47 | Araq | EXetoC: it would be nice if you could fix that missing float32 stuff |
21:58:57 | Araq | pretty embarrassing tbh |
22:03:11 | BitPuffin | zahary: yeeeees oh my god yes :) that would make linagl really awesome |
22:04:14 | gradha | I've seen the term swizzle in dynamic languages, as replacing methods at runtime, is this the same for nimrod? |
22:08:04 | BitPuffin | gradha: that's not really what we are talking about, we mean glsl style swizzling |
22:08:19 | BitPuffin | gradha: https://en.wikipedia.org/wiki/Swizzling_%28computer_graphics%29 |
22:09:47 | zahary | yes, this is sexy only to graphics programmers, but the compiler support needed for it is more exiting, because it can be applied to other domains too. |
22:09:47 | zahary | you'll be able to handle at compile time the calls to unknown procs and reads of unknown fields |
22:10:40 | zahary | it would be possible for a library implementing json values for example to offer natural syntax like |
22:10:40 | zahary | json_value.foo.bar.baz = 10 |
22:10:50 | BitPuffin | zahary: how would swizzling look in nimrod? |
22:10:53 | BitPuffin | just as you post haha |
22:11:19 | zahary | the same way as in HLSL: vec.xz |
22:11:46 | gradha | zahary: for the json example, would the swizzling expand at compile time to the calls required at runtime to navigate that tree? |
22:12:02 | BitPuffin | zahary: well how would you implement it? |
22:12:21 | BitPuffin | zahary: proc `.` (a: Tvector) ? |
22:12:33 | BitPuffin | with a param list? |
22:12:36 | BitPuffin | varargs |
22:12:42 | gradha | Araq: parentDir("/a") returns "", but parentDir("/") returns "/", is that ok? seems asymmetric, would expect both to return "/" |
22:13:09 | zahary | yes, it can be expanded to both compile-time values (templates, statis[string] params, etc) and to a run-time string |
22:13:09 | zahary | it becomes something like |
22:13:09 | zahary | json_navigate("bar", json_navigate("foo", json_value)) |
22:13:20 | zahary | where json_navigate is a proc from the library |
22:14:30 | Araq | gradha: yeah, lets just hope changing it doesn't break anything |
22:14:30 | EXetoC | Araq: I'll try soon. I guess you mean the equivalent of UnaryPlusF64 etc |
22:14:51 | Araq | EXetoC: yeah unfortunately it also needs a compiler patch |
22:15:06 | Araq | will show you how to do it |
22:15:43 | gradha | Araq: is that an invitation for a pull request? |
22:16:30 | gradha | still depends on what you would like to be the "correct" way, leaving it as is may be ok, it just conflicts with the docstring example |
22:17:32 | Mat2 | get some sleep, ciao |
22:17:34 | BitPuffin | will we be able to override array procs too soon for custom array types? |
22:17:39 | BitPuffin | night Mat2 |
22:17:39 | gradha | Mat2 bye |
22:17:52 | * | Mat2 quit (Quit: Verlassend) |
22:19:02 | EXetoC | I guess you don't want distinct for whatever reason |
22:20:03 | EXetoC | but what do you mean by custom? it's either distinct, or an alias |
22:20:03 | BitPuffin | EXetoC: mjeh :P |
22:20:16 | EXetoC | or it's a field, which also solves this problem |
22:20:29 | BitPuffin | EXetoC: well maybe I should make the TMatrix and TVector's distinct arrays |
22:20:31 | Araq | gradha: indeed make a pull request |
22:21:00 | BitPuffin | EXetoC: but then you can't pass a regular array literal i believe, don't you have to do [blabla, blabla].TVector? |
22:21:41 | zahary | Araq, why the compiles magic set gMaxErrors to int(max)? what's the goal here? |
22:21:56 | EXetoC | BitPuffin: Implicit conversions can be provided using a converter |
22:22:08 | EXetoC | I use them for many things. very handy |
22:22:21 | EXetoC | degrees, radians etc |
22:22:28 | zahary | brb |
22:22:56 | BitPuffin | EXetoC: hmm, never used converters |
22:23:02 | BitPuffin | EXetoC: is it a pragma? |
22:23:28 | EXetoC | a keyword |
22:23:38 | BitPuffin | woot |
22:23:46 | BitPuffin | i probably read about it in the manual and forgot |
22:23:46 | gradha | Araq: I was expecting "/" to be returned because / is a special case, but according to the current behaviour maybe it should return ""? Also no idea what happens on windows with drive letters |
22:27:29 | EXetoC | Araq: doesn't seem that difficult though, judging from this grep output |
22:30:29 | Araq | gradha: I think it should return "" and the same for windows |
22:31:40 | dom96 | Araq: gradha: I would make it throw an exception. |
22:32:13 | gradha | the exception is an interesting thought |
22:32:58 | dom96 | Rather than returning a "" which will fail later, and then it will leave you scratching your head about what the hell is going on. |
22:33:26 | gradha | I may take a look at what other langs/libs do |
22:34:56 | EfTwelve | Q: is the there a way get normal formatting when printing floats? i.e 'echo 13.0' should print 13.0, rather than 1.3000000000000000e+001 |
22:35:26 | gradha | EfTwelve: you can use strutils.formatFloat |
22:35:47 | * | Associat0r quit (Quit: Associat0r) |
22:36:28 | gradha | I think it's even common for people to alias that to a shorter proc like ff |
22:37:17 | EfTwelve | i understand. |
22:38:18 | EfTwelve | im i confused? every other language i've ever used does not force e notation. is there reason for the way nimrod does it? |
22:42:35 | gradha | IIRC it has something to do with an old precission bug, this format made it more visible |
22:48:26 | * | io2 quit () |
22:51:25 | EXetoC | I'm sure many people will ask about that |
22:52:05 | gradha | http://forum.nimrod-code.org/t/169 |
22:52:52 | EXetoC | fair enough |
22:53:25 | EXetoC | I just remember being told: "this is better, deal with it" :p |
22:53:52 | * | BitPuffin quit (Ping timeout: 268 seconds) |
22:53:56 | gradha | get a revenge on your memories by submitting a pull request! |
22:55:02 | gradha | "Kill floats", the new Tarantino movie |
23:00:48 | EXetoC | yeah I might |
23:04:54 | * | reactormonk_ joined #nimrod |
23:05:07 | EfTwelve | seems it should be the other way around. if you want e notation you wrap your float in some function to get it. |
23:07:38 | * | reactormonk quit (Ping timeout: 245 seconds) |
23:10:58 | EXetoC | oh, maybe he means 0, but still e notation otherwise |
23:32:05 | * | ltbarcly quit (Ping timeout: 245 seconds) |
23:37:06 | * | EfTwelve quit (Read error: Connection reset by peer) |
23:41:55 | * | Associat0r joined #nimrod |
23:41:55 | * | Associat0r quit (Changing host) |
23:41:55 | * | Associat0r joined #nimrod |
23:42:49 | * | jbe_ quit (Quit: Leaving) |
23:53:41 | * | darithorn quit (Read error: Connection reset by peer) |
23:57:44 | gradha | good night |
23:57:57 | * | gradha quit (Quit: bbl, need to watch https://www.youtube.com/watch?v=fS9CcTpA9i0 again) |