<< 14-10-2013 >>
00:05:18*melba_ joined #nimrod
00:05:23*melba quit (Read error: Connection reset by peer)
00:48:49*rel42 joined #nimrod
00:52:16*melba_ quit (Ping timeout: 256 seconds)
00:59:14*q66 quit (Quit: Leaving)
01:28:19*rel42 quit (Quit: Leaving)
01:38:00*OrionPK quit (Quit: Leaving)
01:40:22*gdos quit (Read error: Operation timed out)
01:50:28*XAMPP-8 joined #nimrod
02:03:54*ltbarcly joined #nimrod
02:08:28*ltbarcly quit (Ping timeout: 240 seconds)
02:14:37*gdos joined #nimrod
02:19:28*XAMPP-8 quit (Ping timeout: 240 seconds)
02:48:27*XAMPP quit (Read error: Connection reset by peer)
02:54:24*gdos quit (Read error: Connection reset by peer)
03:12:19*brson quit (Quit: leaving)
03:14:22*gdos joined #nimrod
03:19:21VarriountBest way to quickly get a stack trace of a location in code: assert(0==1) :3
03:21:36Demosnice, that will be good for those times when visual c++ decides exceptions are not worth keeping stack traces for
03:22:28VarriountDemos, I have been, for the last 2 hours, trying to track down an elusive bug affecting the socket functionality in nimrod
03:22:37VarriountBut the bug only appears on 64 bit builds
03:23:11Demosactually I would enjoy seeing an option in c++ (and nimrod I spose but the effects stuff makes it a little un-nessassary) to disable exceptions and replace throw/Raise with terminate() but ONLY for code internal to my project
03:23:22Demoshmmm
03:23:42Demosall systems or only windows-64
03:23:48VarriountWin64
03:24:04VarriountSO all you Linux-Masters are safe. :p
03:24:37Demosyou on windows7 64?
03:25:03VarriountWin8
03:25:29DemosOK I was going to point you toward KB2864432 (the AVX on x64 stack trace bug)
03:25:40Demoswant someone to test it on 8.1
03:25:46Varriount?
03:26:10Demoswin 7 64 corrupts stack traces when a 64 bit app crashes on a computer with AVX enabled
03:26:22VarriountEww, ouch
03:26:29Demosoh it may only be 32bit apps
03:26:42Demosdoes Nimrod64 even build?
03:26:46VarriountYes
03:27:10Demoshm, I got a bad check in some of the c bootstrap sources
03:27:40VarriountDemos, make sure to add the src directory to the build64.bat file
03:28:00VarriountEr, add it to the list of directories to search for includes.
03:28:00Demosherpderp, will do, someone should pop that into the git repo
03:30:24VarriountDemos, you're using gcc/mingw64, right?
03:30:43Demoserm maybe, I /think/ I am using gcc/cygwin64
03:30:55Demosideally I would be using MSVC but meh
03:31:05VarriountMSVC Doesn't work out of the box
03:32:10VarriountActually, it might not work at all, given that it doesn't even fully support C99
03:32:24Demoswell MSVC12 is a little better
03:32:37Varriount'little'
03:33:03Demosyeah, anyway the error is that the array at the bottom of nimbase.h has a negitive index
03:33:37VarriountHm. You're using the version from the repository?
03:34:06Demosyeah from the csources repo
03:34:30VarriountIs it a nimrod compiler error, or a gcc error?
03:34:46Demosgcc, on compiling the csources for bootstrap
03:34:58Demosgcc is at version 4.5.2
03:35:27VarriountHm, mine is 4.8.2
03:35:50*Endy joined #nimrod
03:36:07Demosoh dear god my gcc is from an old version of haskell-platform!
03:36:26VarriountEwww....
03:36:53Demosand hell, it is a 32bit version, so derp
03:37:11Varriount*cough*Mingw64*cough*
03:38:04Demosima use cygwin64, already have that anyways
03:38:15Demosbig derp on my part
03:38:39VarriountDemos, I actually have both 32 and 64 bit builds on my computer.
03:40:21*dyu_ joined #nimrod
03:53:40Demosnuts, gcc is stuck in my path :9 ima fix it tomorrow
03:54:22VarriountThe solution to that is to use different batch files to set up the PATH for different purposes
03:55:03Demoswell yes, but there were other problems. honestly I may change build.sh to allow cygwin
03:55:12VarriountI have two, one to set my path to use certain 32 bit versions of a set of programs, the other to use the 64 versions
03:55:37Demosit is even worse since the path seems to be differnt in cygwin vs powershell vs COMMAND.COM
03:55:53Varriount^ Why I don't use Cygwin
03:56:23Demosyeah, but it is an easy way to get stuff like ssh, X windows, git, and so on. Things I need for shcool
03:57:18VarriountHrm, I don't know about X Windows, but Msys and Mingw do a pretty decent job for utilities like git and ssh
03:58:18Demosyou just compile everything with mingw? ideally we could do that with MSVC, imo if you are writing C in the first place you may as well write C89
03:58:42VarriountDemos, not if the source files have no makefiles for MSVC
03:59:08Demoswell we would all use cmake :D
04:00:11VarriountDemos, I can give you a 64 bit binary, you know
04:00:33Demosna, I can do it when it is not 12AM
04:00:58VarriountWhere do you live? It's the same time here.
04:01:09Demosbro, look at my hostname
04:01:49VarriountCountry: Educational Institution :3
04:02:58Demosanyhow I am going to sleep, see you tomorrow
04:03:20VarriountGood night. Be very quiet, I'm hunting bugz.
04:03:30Demosgood luck!
04:03:40VarriountI've narrowed it down to a handful of functions.
04:04:03*Demos quit (Quit: Leaving)
04:15:25*DAddYE joined #nimrod
04:57:44*isenmann joined #nimrod
05:00:09*ponce is now known as Guest87205
05:29:48*Endy quit (Ping timeout: 240 seconds)
05:39:11*Associat0r quit (Quit: Associat0r)
05:53:10*ltbarcly joined #nimrod
05:54:24*XAMPP joined #nimrod
05:54:26*XAMPP quit (Changing host)
05:54:26*XAMPP joined #nimrod
06:02:01VarriountFor all those interested ( dom96, Araq ) I've narrowed down the Win64 socket bug to asyncio.poll and one of its subprocedures, asyncio.pruneSocketSet
07:15:30*Guest87205 is now known as ponce_
07:42:12*Varriount pounces on ponce_
07:42:47*ltbarcly quit (Quit: Computer has gone to sleep.)
08:58:12*melba joined #nimrod
09:11:20*DAddYE quit (Remote host closed the connection)
09:11:49*DAddYE joined #nimrod
09:16:01*DAddYE quit (Ping timeout: 245 seconds)
09:36:37*q66 joined #nimrod
10:12:36*DAddYE joined #nimrod
10:18:56*DAddYE quit (Ping timeout: 265 seconds)
11:15:17*DAddYE joined #nimrod
11:20:02*DAddYE quit (Ping timeout: 264 seconds)
11:43:31shevyhehe
11:44:21*Boscop is now known as Bosc0p
11:44:39*Boscop joined #nimrod
11:44:41*Boscop quit (Changing host)
11:44:41*Boscop joined #nimrod
11:50:21*gdos quit (Read error: Operation timed out)
11:51:40*Boscop quit (Quit: Boscop)
11:52:21*Boscop joined #nimrod
11:53:24*Boscop quit (Client Quit)
11:55:08*Boscop joined #nimrod
11:55:09*Boscop quit (Changing host)
11:55:09*Boscop joined #nimrod
12:15:55*DAddYE joined #nimrod
12:22:35*DAddYE quit (Ping timeout: 260 seconds)
12:31:44*Endy joined #nimrod
12:33:54*[1]Endy joined #nimrod
12:34:07*jbe_ joined #nimrod
12:36:48*Endy quit (Ping timeout: 240 seconds)
12:36:48*[1]Endy is now known as Endy
12:37:09jbe_hello
12:37:47jbe_what is the nimrod equivalent of INT_MAX again?
12:52:44*Ricky_Ricardo joined #nimrod
13:08:02jbe_ok nevermind, i found out, it is high(int)
13:16:53*girvo joined #nimrod
13:18:48*DAddYE joined #nimrod
13:21:09*wlhlm joined #nimrod
13:23:18*DAddYE quit (Ping timeout: 252 seconds)
13:38:11EXetoCbadger badger badger badger badger badger badger badger
13:39:20jbe_mushroom mushroom
13:41:47EXetoCc(:)=|<
13:42:21girvoahhhhh
13:42:23girvoit's a snaaaaaake
13:45:12EXetoCwhere?
13:48:42Araqhi girvo welcome
13:48:56girvohey Araq :) hows it going?
13:49:08jbe_i used to tap away to that song in stepmania, fond memories
13:49:58AraqI integrated my new VM in the compiler and it works :-)
13:50:15girvoLove that feeling, right? :)
13:50:20girvowhat's the new VM like?
13:50:28AraqI'm used to the feeling :P
13:50:49Araqthe new VM is a register based bytecode VM
13:51:07girvoNeat. what was the old architecture?
13:51:10Araqfor our compile time evaluation pleasures
13:51:22Araqthe old vm was a simple AST-based interpreter
13:51:59girvoahhh fair enough!
13:52:55girvodidn't the macro system utilise the AST for transformations? howd you tackle porting that behaviour? I will say i've never really touched proper VM's, i've always stuck to pretty boring interpreters for my toy projects
13:53:55Araqthe VM still operates on ASTs
13:54:15Araqbecause as you say this is what macros deal with
13:59:07Araqand in case you wonder:
13:59:48Araqthis means Nimrod runs your code faster at compile time than Python does at runtime ;-)
14:00:15EXetoCFK YEAH
14:00:56EXetoCand without any duck impostors
14:04:38girvoAraq: I was wondering about performance there! can't wait to give it a spin
14:04:44*girvo quit (Remote host closed the connection)
14:09:12EXetoCwell, duck impostors at run-time anyway
14:17:02EXetoCso no one else has picked up that lambda project, eh?
14:17:06EXetoCwill try to get it done by christmas
14:19:28*DAddYE joined #nimrod
14:20:07Araqhuh?
14:20:15Araqwhat's the lambda project?
14:20:25EXetoCnot so much a project really
14:20:27EXetoC\(x + y)
14:20:46Araqah ok
14:20:50Araqyeah do it
14:21:04Araqthe new vm fixes many macro eval bugs though
14:21:16Araqso it might be better to wait until it's pushed
14:21:43*Ricky_Ricardo quit (Quit: Ricky_Ricardo)
14:21:53EXetoCwould language support for just "x + y" be feasible? it's still short though, and that could be the first step
14:21:56EXetoCok I'll wait
14:22:46AraqI can't see how simply "x+ y" can work
14:23:06EXetoCI just realized how silly that was
14:23:13EXetoCthe former is fine
14:24:31EXetoCf(º x + y, z). awesome
14:26:21*DAddYE quit (Ping timeout: 272 seconds)
14:32:26*gdos joined #nimrod
15:03:54*zanoni quit (Remote host closed the connection)
15:13:11*zanoni joined #nimrod
15:22:20*DAddYE joined #nimrod
15:23:29*shafire joined #nimrod
15:23:51shafirehi
15:28:38*DAddYE quit (Ping timeout: 240 seconds)
15:39:52dom96hello
15:40:46shafirehey dom96
15:40:58shafireI found old nimrod posts and code from you
15:41:13dom96oh?
15:41:15shafireMay I ask, how you found out about nimrod in that early time?
15:41:25dom96Wikipedia.
15:41:46dom96I was looking at the Python article and saw Nimrod in the "influenced" section.
15:42:19shafirehttp://en.wikipedia.org/wiki/Python_%28programming_language%29 <- have they removed it?
15:42:29dom96yeah
15:42:58dom96They removed it a couple of weeks after I found it, so it was pretty lucky.
15:43:31shafireyeah, did not have such luck ;(
15:44:30dom96I tried getting the article back but they take it down due to lack of significance
15:44:40dom96so please blog about Nimrod if you can
15:46:57VarriountDoes Speaking of which, why isn't there a wikipedia article on nimrod?
15:47:11VarriountAlso, good morning.
15:47:15dom96because they took it down due to lack of significance.
15:47:30Varriountdom96, That is no excuse.
15:47:48dom96http://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion/Nimrod_%28programming_language%29_%282nd_nomination%29
15:48:19VarriountBelieve me, there's quite a lot of programming language articles that could fall under that heading, and yet have stayed on wiki[edia.
15:48:26dom96yep
15:48:30dom96I gave examples in that talk page.
15:48:46dom96http://en.wikipedia.org/wiki/Io_(programming_language) is still alive
15:49:44dom96I can give you the source of the article I wrote if you guys wanna resubmit it and fight with the WP moderators.
15:50:25Varriountdom96, Just make sure the source doesn't get deleted. If we can find more online sources, then we can fight the moderators.
15:50:57VarriountUnfortunately, I've found that in communities like these, bone headed stupidity tends to win out over common sense.
15:51:00shafirelol
15:51:01dom96There is at least one notable reliable source which is not primary nowadays: steved or whatever his name is wrote a blog post some time ago.
15:51:19shafireI could write some nimrod case study and publish it through my university
15:51:27shafireso we can cite from :D
15:51:33VarriountThat would be very good
15:51:47dom96shafire: that would be awesome.
15:52:24dom96Perhaps it is worth resubmitting now. On the talk page Lesser Cartographies wrote "Perhaps think of it this way: a language becomes notable when people who haven't been involved in its creation start writing about it. If/when this language gets to that point you'll have no problem creating an article. At the moment, though, there just hasn't been enough uptake to get the coverage we need for notability."
15:52:41dom96That has been the case.
15:52:46shafireand wasn't there a talk about nimrod on a conference?
15:52:56VarriountI noticed that one of the reasons for deletion was "lack of secondary sources"
15:53:16dom96But then someone else wrote "No, sorry. Blogs and other self-published sources are not considered WP:RELIABLE sources for purposes of establishing WP:Notability at AfD. Further, the author of the blog appears to be anonymous, rendering this source especially weak. "
15:53:28dom96If blogs are not considered reliable then wtf is!?
15:53:29shafireI see, "No, that's an advertisement for a talk given by the author. It is not independent of the subject"
15:53:47dom96Yeah, we mentioned the talk to them.
15:53:49*io2 joined #nimrod
15:53:53shafireI think, we need some papers using nimrod
15:53:59shafiremaybe a technical paper
15:54:05profmakxdom96 peer reviewed journal publications
15:54:11profmakxbecause they are not tainted by aything!
15:54:58io2you need to solve a particular problem with nimrod in order to publish to non - general interest trade journals.
15:55:24io2which means one has to identify a specific problem and demonstrate where nimrod's approach is superior
15:55:35VarriountHm.
15:55:52profmakxor. just not care about WP wankers with their notability shit
15:55:53io2Right now, the most interesting aspect when it comes to metaprogramming, is related to its term rewriting macros and AST techniques
15:56:14VarriountPossibly my translation of neil frasiers diff0match-patch library might suffice
15:56:16io2I believe that a paper on that would attract a lot of interest
15:56:31dom96well we have some university people here, write us some peer reviewed journal publications guys!
15:56:37io2Araq: any ideas on that ^
15:56:40Araqthere is an article about it, but it's from me
15:56:44Araqso it doesn't count
15:57:09io2How about doing a paper on metaprogramming with nimrod :)
15:57:10AraqI can write whole books about nimrod but it wouldn't count for wikipedia
15:57:23Araqsomebody else gotta do it
15:57:36io2one at least, could.
15:58:42AraqI have to leave, gye
15:58:44Araq*bye
15:59:03io2bye boss
15:59:09dom96*BDFL
15:59:43Varriountdom96, Did you get my message about the Win64 socket bug?
15:59:48io2Seems to me I should start gathering the various notes and test I have been playing with in nimrod's macros, hope to find the time for it.
15:59:55io2Something could come out of that.
16:00:05io2hi dom96, how is jester doing :)
16:00:31dom96Varriount: Yeah, what's wrong with pruneSocketSet?
16:00:40dom96io2: I'm not really working on it heh
16:02:17io2let me guess, little time :)
16:02:51dom96Yeah. School sucks :\
16:03:01Varriountdom96, I'm not quite sure, all I have debug output
16:03:26dom96Varriount: How did you narrow it down?
16:03:44VarriountComparing debug output between 32 and 64 bit builds
16:05:39dom96nice. Did you just spam it with lots of 'echo's? lol
16:05:53Varriountdom96, let me show you the output
16:07:41Varriountdom96, http://pastebin.com/gcQWuJw8
16:08:14Varriountand http://pastebin.com/nis8kV9L
16:10:19*Associat0r joined #nimrod
16:11:17dom96hrm, I guess your line numbers don't match the original
16:11:37dom96but yeah, I can see the first significant difference start at 554
16:12:05VarriountAll I know is that in the 32 bit build, the len(writefds) decreases by 1 in the asyncio.select procedure, after that procude calls the pruneSocketSet procedure
16:12:15VarriountIn the 64 bit build, it doesn't
16:13:29dom96right, hrm.
16:14:26dom96what's 553?
16:14:34VarriountMy suspician is that it has something to do with FD_ISSET, but I can't find any major differences with it
16:14:47Varriount553 is the call to FD_ISSET
16:15:04dom96its return value?
16:15:11VarriountOh wait, I was wrong
16:15:17Varriount553 is print(s[i].fd)
16:15:39Varriountin asyncio.pruneSocketSet
16:15:40dom96oh nah, I don't think that's significant
16:16:19dom96is 551 just you printing 'fd'?
16:16:29VarriountYes.
16:16:29EXetoCAraq: let someone else take the credit
16:17:09Varriountdom96, 554 is print(FD_ISSET(s[i].fd, fd))
16:17:38dom96I wonder why the fd_count is 0 and yet fd_array still contains the file descriptor.
16:18:08VarriountI don't know, but that's what the working 32 bit version does.
16:18:38VarriountFor the read and error file descriptors, anyway
16:21:10VarriountI mean, it changes the fd_count for the read and error file descripters from 1 to 0, and keeps the write fd at 1
16:21:56Varriountdom96, the fd_count determines how far the FD_ISSET function searches the array
16:22:09VarriountAmong other things.
16:22:50VarriountSorry if I'm a bit incomprehensible, I spent about 5 hours yesterday tracking down this bug
16:23:23dom96well, it looks to me like fd_isset is wrong
16:23:55dom96the fd set contains 216 and fd_isset returns 0
16:24:11VarriountYes, but why?
16:24:47dom96Try changing the 'bool' in https://github.com/Araq/Nimrod/blob/master/lib/windows/winlean.nim#L478 to a 'cint'
16:24:57dom96and then just return the value in FD_ISSET
16:27:25*shafire left #nimrod (#nimrod)
16:30:57guaquais there some easy way of calculating the closest power of two of a number (since it seems to be a requirement for example for initSet)?
16:34:06Varriountdom96,On 32 bit FD_ISSET returns, when changed to a cint, 0 for the read fd, 1 for the write fd, and 0 for the error fd,
16:34:34dom96and 64bit?
16:34:38VarriountOn 64 bit, ti returns 0 for the read fd, 0 for the write fd, and 0 for the read fd
16:35:16*shodan45 quit (Remote host closed the connection)
16:37:34*shodan45 joined #nimrod
16:38:00dom96Now I wonder why the fd_count is 0 on 32bit
16:39:07dom96Apparently this is how WSAFDIsSet looks like: http://www.c-worker.ch/dokuwsck/owinsck/winsockb.htm
16:39:11dom96(B.5 ...)
16:39:48dom96So if fd_count is 0 how does it work?
16:40:37*Varriount quit (Ping timeout: 272 seconds)
16:41:30*Varriount joined #nimrod
16:41:58VarriountWhat did I miss?
16:42:17dom96http://build.nimrod-code.org/irclogs/
16:43:53Varriountdom96, fd_count controls how much of the array is searched by FD_ISSET
16:44:07VarriountI think
16:44:24dom96fd_count is the amount of file descriptors in the set
16:44:48dom96in any case, why is it 0 on 32bit?
16:45:12dom96if FD_ISSET searches nothing then why does it return 1?
16:45:48Varriountdom96, look at http://msdn.microsoft.com/en-us/library/windows/desktop/ms737873(v=vs.85).aspx
16:46:35Varriountfd_set has a fixed sized array
16:50:23*BitPuffin quit (Ping timeout: 272 seconds)
16:51:18Varriounthttp://msdn.microsoft.com/en-us/library/windows/desktop/ms741578(v=vs.85).aspx
16:52:05dom96is that relevant?
16:52:32VarriountThats the underlying call FD_ISSET makes
16:52:49VarriountReturns 1 if fd is part pf the set, 0 if not
16:53:13dom96yes, but if fd_count is 0 then it thinks that the fd_set is empty
16:53:22dom96so it should return 0
16:53:33VarriountYes
16:53:38*fowl joined #nimrod
16:56:41*DAddYE joined #nimrod
16:56:51dom96so 32bit is incorrect too lol
16:57:00Varriountdom96, in short, the fd_count for the read and error fd's is wrong
16:57:07Varriount32 bit isn't
16:57:35dom96oh wait
16:57:42dom96I don't know which is which now.
16:57:59VarriountAre you looking at the [astebins?
16:58:00dom96You print out 3 fd sets
16:58:03dom96yeah
16:58:15VarriountThe second one is is the write fd
16:58:31Varriountthe first is the read fd
16:58:37Varriountand the last is the error fd
16:59:10dom96ohhh
16:59:14VarriountOn 32 bit, the fd_count for the read and error fd_set's is 0
16:59:15dom96ok, so yeah. 32bit is correct.
16:59:25Varriounton 64 bit though, it's not
16:59:42VarriountWhy..?
16:59:53dom96it is correct for writeFd
17:00:39dom96and yet FD_ISSET still fails
17:03:17VarriountActually, it doesn't
17:03:36Varriount0 means that the fd is part of the set
17:03:47dom96lol
17:03:51*dom96 facepalms
17:04:13VarriountWhat sets the count on those fd_set's?
17:04:39dom96yeah, this makes sense.
17:04:50dom96The FD is removed from the FD set
17:04:58dom96when its state changes
17:05:02VarriountWhere?
17:05:09dom96select does it
17:06:01dom96huh
17:06:06dom96Docs say "Nonzero if s is a member of the set. Otherwise, zero."
17:07:12VarriountFD_ISSET(s, *set)
17:07:13VarriountNonzero if s is a member of the set. Otherwise, zero.
17:07:22VarriountI was wrong.
17:07:38dom96indeed
17:07:48dom96check the return value of 'select'
17:08:29dom96Yeah, pruneSocketSet makes sense.
17:09:09VarriountAs in, is working, or has the bug?
17:09:21dom96is working
17:10:49*brson joined #nimrod
17:12:11Varriountdom96, 1 on 32 bit, -1 on 64 bit
17:12:47dom96lol
17:13:32dom96add:
17:13:32dom96if select(..) == -1: OSError(OSLastError())
17:16:00Varriount64 bit errors, 32 bit doesn't
17:16:07dom96what's the error?
17:22:25VarriountUnknown OS Error
17:22:26VarriountEOS
17:22:33dom96gah
17:22:50dom96That's helpful gah
17:24:14fowllol
17:25:00Varriountdom96, the actual error code is zero
17:25:55VarriountWhich means that the OS didn't recieve ane
17:26:18dom96try running WSAGetLastError
17:28:18fowlAraq, i'd love to play with this new VM of yours
17:30:08*shodan45 quit (Ping timeout: 245 seconds)
17:30:24Varriountdom96, I'm gonna take a break on this for a bit, I'm falling asleep in my keyboard
17:30:45VarriountThanks for your help so far, it's an infuriating bug
17:30:48dom96hehe alright. You've done well so far.
17:31:13*Varriount is now known as Varaway
17:31:59*shodan45 joined #nimrod
17:32:35*shodan45 quit (Client Quit)
17:33:06*shodan45 joined #nimrod
17:36:21*rel42 joined #nimrod
17:52:06*rel42 quit (Quit: Leaving)
17:53:25*dyu_ quit (Quit: Leaving)
18:01:24*BitPuffin joined #nimrod
18:06:23*ltbarcly joined #nimrod
18:10:47*ltbarcly quit (Ping timeout: 260 seconds)
18:12:56*ltbarcly joined #nimrod
18:24:35*BitPuffin quit (Ping timeout: 245 seconds)
18:32:28*BitPuffin joined #nimrod
18:40:51wlhlmIt seems like that the nimrod language definitions are removed from sublime-text entirely…
18:41:02wlhlm(version 3)
18:43:00fowli've never seen nimrod in their list, i believe i use version 2
18:43:09fowli've always set .nim to python and be good with that
18:45:28wlhlmahh, it looks like they are available externally: https://www.dropbox.com/s/84gtcgjmw2ec61r/Nimrod-Sublime.zip
18:52:28Araq2 more and we have a record!
18:52:42fowltwo more what
18:52:44*Araq pushes DAddYE to stay around
18:52:54Araq2 more people
18:52:55fowloh
18:53:13DAddYEAraq: here I am!
18:53:19Araqyay
18:53:23DAddYE(but I'm going to lunch XD
18:53:29Araqinvite 2 friends
18:53:35Araqbut they have to be female :P
18:55:36Araqfowl: I'll push a newvm branch tonight
18:56:19Araqbut expect bugs
18:58:30fowlsweet
19:01:53AraqI also plan to make 'compileTime' variables persistent
19:02:24Araqthis means ID generators etc work for cross modules
19:03:04fowlcool
19:03:54Araqthey will be stored in the "nimrod.gid" file so they are even cross project
19:04:11Araqbut this can of course cause lots of problems
19:04:36fowlmaybe that should require {.compiletime,global.}
19:04:58Araqwell it only makes sense for globals
19:05:35Araqthe 'global' pragma is strange for a variable that is a global anyway
19:06:57fowlI thought I saw someone implemented tiled tile sheet library in nimrod
19:07:26Araqmaybe a 'persistent' pragma is required here
19:07:45io2what the ... http://en.wikipedia.org/wiki/Nimrod_%28programming_language%29 <--- DELETED?
19:07:48Araqor perhaps: compileTime: "filename.here"
19:08:09Araqio2: wikipedia surely is trying hard to become irrelevant :P
19:08:28fowlis there a programming wiki
19:08:43io2Araq: are you sure there isn't something else going on?
19:08:43Araqthere is rosetta code and we're there
19:08:44fowlnot some wikia, but a notable wiki about programming to target instead of wikipedia
19:08:49io2this is weird, nimrod is legitimate
19:09:19dom96It's a conspiracy by Google and Mozilla to make Nimrod less known :P
19:10:25io2i think it is a question of apps mostly
19:10:38io2i will read the rationale, this is weird
19:10:54Araqthe rationale makes some sense
19:11:21Araqexcept that according to it 70% of all articles on wiki should be deleted
19:11:55wlhlmweird, that it isn't at least in the english wikipedia, I always thought notability related discussions were special for the german wikipedia…
19:12:04io2"Delete. Language is quite new and hasn't yet gained notability. Does not meet guidelines laid out in WP:NSOFT. Lesser Cartographies (talk) 11:43, 25 August 2013 (UTC)"
19:12:56io2http://en.wikipedia.org/wiki/Io_%28programming_language%29 <--- dom96 really knows where to find these things!
19:13:13dom96Yeah, I wanted to make a good argument.
19:13:22dom96So I looked through some programming language articles.
19:13:58dom96That article is still there, and it still has only 1 reference.
19:14:18dom96Which is a primary source.
19:15:41dom96I think we should just add it again.
19:15:45wlhlmI've read a ton of computer related articles without even one reference (en.wikipedia.org), they were marked as stub, but at least they were accessible
19:16:54io2practically, even if nimrod is used by NASA, that will not be a primary source until voyager reaches alpha centauri
19:17:01io2right
19:17:15wlhlmio2: :P
19:17:21EXetoCmakes sense
19:19:40io2http://en.wikipedia.org/wiki/Fancy_%28programming_language%29 << dom96
19:19:54io2I see lots of interesting things in the references
19:20:04*ltbarcly quit (Quit: Computer has gone to sleep.)
19:21:57dom96Here is a copy of the article: https://en.wikipedia.org/wiki/User:Dom96/sandbox
19:33:44io2fancy has the same kind of references btw
19:37:51dom96So, is anyone up for resurrecting the article?
19:38:14io2don't have an account yet
19:38:29io2and I know little about wikipedia things, how they work out i mean
19:39:04io2i guess the only thing I could do would be to start writing that thing I have in mind about macros
19:39:38dom96yeah, do that.
19:40:13fowlcool i just found the events module
19:59:10*fowl quit (Ping timeout: 245 seconds)
20:04:48*wlhlm quit (Ping timeout: 252 seconds)
20:06:56*ltbarcly joined #nimrod
20:18:25dom96Araq: I think exception handling on arm is broken. I compiled and ran a simple 'assert false' and it segfaulted.
20:19:41*fowl joined #nimrod
20:19:52dom96And yeah, it looks like that is the problem I am having.
20:20:24Araqwith --threads:on ?
20:20:30dom96no
20:20:43dom96just 'nimrod c -r test.nim'
20:21:26*Demos joined #nimrod
20:21:49fowli think i found a regression
20:22:09*ltbarcly quit (Quit: Computer has gone to sleep.)
20:22:44fowlthis doesn't work anymore https://github.com/fowlmouth/nimlibs/blob/master/fowltek/entitty.nim#L492
20:22:45Araqfowl: ok, report it, but I know of so many regressions already that it's not even funny
20:22:54Araqyeah know about it
20:22:56Demoshm I just built a 64-bit version of nimrod on my windows computer, when I compile a file that exports for c functions with {.cdecl, exportc, dynlib.} without --app:lib I get an error, then I get an error the firs two times I compile /with/ --app:lib, after that is works fine
20:23:19fowlAraq, oh ok
20:23:30fowlalso i had to make allComponents {.global.} for it to work
20:23:48fowland i remember having to make it not {.global.} to make it work before..lol
20:23:48Demosoh, it just stops even calling gcc
20:24:33Demosare there problems compiling nimrod with winthreads and seh?
20:27:54Demosoh heay, had to delete nimcache, herpderp
20:28:10fowllol
20:32:14Araqfowl: nope, I was wrong report it please
20:32:25Araqin fact, I should add that to the test suite
20:33:07fowlit seems to work sometimes
20:33:53fowlwhen i try it alone its working fine
20:34:03*Endy quit (Ping timeout: 248 seconds)
20:37:41dom96Araq: so, any idea how to debug this?
20:39:10Araqdebug it with gdb
20:40:18dom96yeah, I am. It ends up on line 5091 of system.c (addChar) with a corrupted stack.
20:41:25Araqwtf
20:41:29Araqinteresting
20:41:48Araqso that's the bug
20:43:05dom96I'll gdb the same program on x86 and compare the values.
20:46:10Araqwhat values do you want to compare?
20:46:19Araqalso try it with --gc:none please
20:54:48dom96crash happens in auxwritestacktrace
20:54:55*jbe_ quit (Quit: Leaving)
21:04:13*zanoni quit (Remote host closed the connection)
21:07:58*zanoni joined #nimrod
21:08:46dom96Araq: As soon as it gets into the 'addChar' proc the stack is corrupted.
21:09:09Araqbut before that it's not?
21:09:28dom96according to gdb at least
21:10:42dom96https://gist.github.com/dom96/3dab418833d3daea046d
21:13:09Araqtried the same with --gc:none ?
21:13:26dom96i'll try now
21:13:59*Varaway is now known as Varriount
21:14:42dom96Araq: Still segfaults
21:14:48dom96Araq: Want me to gdb it too?
21:14:49VarriountSo Araq, dom96 and I have narrowed down where the Win64 socket bug lies.
21:17:21AraqVarriount: awesome
21:17:25Araq:-)
21:17:49VarriountIt's somewhere in Asyncio.poll
21:18:17VarriountAnd relates with the write descripters fd_count
21:18:46dom96The bigger problem is that select returns -1
21:18:50dom96indicating an error
21:19:57Araqdom96: yeah please
21:24:31dom96Araq: it's exactly the same
21:24:51*zahary quit (Quit: Leaving.)
21:25:19Araqdom96: try with -d:noSignalHandler
21:27:35dom96no change
21:28:01Araqin gdb please do:
21:28:04Araqprint *x
21:28:36Araqjust before 'addchar' corrupts the stack
21:28:42dom96$1 = (NimStringDesc *) 0xb6de2028
21:28:54Araqprint **x
21:29:07dom96yeah, that doesn't something weird.
21:29:14dom96It gives nothing
21:29:18dom96and looks as if it hangs there
21:29:55*ltbarcly joined #nimrod
21:30:04dom96hrm, I guess it is doing something
21:30:08dom96It's using 100% CPU
21:30:31*ltbarcly quit (Client Quit)
21:33:12dom96on my desktop it just says "Cannot access memory at address 0x7ffff7f46050"
21:33:49Araqer what?
21:34:00Araqstack traces are broken on your desktop too?
21:34:33dom96no
21:34:45dom96I've ran the same app to compare
21:35:08Araqwhat app?
21:35:35dom96var x = newException(EIO, "blah")
21:35:35dom96echo x.msg
21:35:35dom96raise x
21:35:46*ltbarcly joined #nimrod
21:36:03*ltbarcly quit (Client Quit)
21:40:12Araqprint x->len
21:40:59dom96There is no member named len.
21:47:28*DAddYE quit (Read error: Connection reset by peer)
21:47:52*DAddYE joined #nimrod
21:49:58dom96Araq: I will have to go to sleep eventually... any other ideas?
22:13:09VarriountOk... this is really odd..
22:13:36VarriountWinselect is returning -1, but there is no windows error code for -1...
22:13:59*ltbarcly joined #nimrod
22:14:50*ltbarcly quit (Client Quit)
22:16:47dom96You're suppose to use GetLastError to get the error code
22:16:53dom96-1 just means "an error happened"
22:18:11Varriountdom96, GetLastError returns 0
22:18:29dom96have you tried WSAGetLastError?
22:18:30fowlWSAlasterror()
22:19:59Varriountdom96, That too, returns 0
22:20:06*OrionPK joined #nimrod
22:21:57Araqthat's not weird
22:22:09AraqI remember we had the same problem on win32
22:22:23VarriountAnd how did you track it down?
22:22:45Araqthe reason was that the memory manager was invoked in between which called HeapAlloc or something
22:23:02Araqwhich reset the internal error code to 0
22:23:12Araqtook us days to figure it out :P
22:23:22dom96yes, just make sure to call GetLastError immediately after the call to select
22:23:36dom96And by 'select' I mean the winapi select
22:23:59VarriountYou mean like I am?
22:24:01Varriount var result = wselect(nfds, readfds, writefds, exceptfds, timeout)
22:24:01Varriount print(WSAGetLastError())
22:24:17Varriountwselect being the windows select function I renamed and wrapped
22:24:50dom96maybe your 'print' does something?
22:24:54AraqVarriount: check the generated C code
22:25:00Araqand try it with -d:release
22:25:15Araqrelease mode disables lots of checks that could interfere here
22:26:28Araqdom96: print x->Len ?
22:27:03Varriount*facepalm*
22:27:18VarriountMy print template was allocating memory...
22:27:29VarriountAnd thus erasing the error code.
22:27:58dom96Araq: it's x->Sup->len
22:28:03dom96Araq: 34
22:28:05Araqdom96: ah sorry
22:28:26VarriountError 10038
22:29:01VarriountWSAENOTSOCK
22:29:14dom96Varriount: You can call OSError on it now
22:29:24dom96to get a nice error message hopefully
22:29:50Araqsorry, dom96 told me to make the allocator not erase the error code but I refused due to performance/dependencies reasons iirc
22:30:13dom96yeah...
22:30:25VarriountAraq, might want to warn others of that then.
22:30:35VarriountIn big, bold letters somewhere
22:30:45Araqyup
22:30:55Araqor perhaps we can fix it
22:31:07dom96http://build.nimrod-code.org/docs/os.html#122
22:31:14dom96A warning is in the docs :P
22:31:54dom96But it should mention that memory allocs can cause this.
22:31:54Araqdom96: ok but we need an example that triggers this issue
22:32:45*BitPuffin quit (Ping timeout: 272 seconds)
22:32:50Araqactually it shows this "return value == -1 and get error code from somewhere then" is a stupid design
22:33:13VarriountWhat's a better design?
22:33:21Araqthings would be much easier if it would simply return an error code instead
22:33:37dom96The fix is simple. Just make the allocator reset the error code. But yeah yeah, it's a performance problem.
22:34:01Araqdom96: no it also was a dependency issue iirc
22:34:30Araqso it wouldn't work on win95 anymore or something
22:34:50VarriountAraq, I doubt there are many companies out there using win95
22:35:07VarriountPossibly Windows 2000
22:35:10AraqI'm sure we would find out some poor soul used it on win95 without any problems but now it broke his code
22:35:34dom96Does the compiler ever work on Win 95?
22:35:37dom96*even
22:35:50Araqit works on win xp, I check from time to time
22:35:59Araqdunno about win95
22:36:02dom96Win XP is a long way from Win 95
22:36:20VarriountAnyway, back to matter at hand... why is it saying that the socket is not a socket?
22:36:56dom96Araq: I need to go to sleep soon, so please help me debug this.
22:37:07AraqVarriount: you should also run it with -d:useSysAssert -d:useGcAssert
22:37:17Araqdom96: I'm already sleeping
22:37:58Varriountdom96, Sleeping at 6:30 pm?
22:38:02dom96Araq: So you won't help me then?
22:39:00Araqprint x->Sup->cap
22:39:11Araqer
22:39:15Araqprint x->Sup->reserved
22:39:33dom9666
22:40:43*ltbarcly joined #nimrod
22:40:59AraqseqShallowFlag has been miscompiled for your cpu I think
22:41:17Araqit produces some int64 literal in the C code. It shouldn't
22:41:41Araqit needs to produce an int32 literal on a 32bit cpu
22:41:53dom96ok, so where is that set?
22:42:04Araqsystem.nim
22:42:08Araqline 852
22:45:36Araqtry: seqShallowFlag = 0b1000_000_000_000 instead
22:45:50Araqthat's not the same, but might circumvent the bug
22:46:12dom96well I just echo'd what it is: 2147483648
22:46:46Araqok
22:46:49Araqthis is wrong
22:46:59Araqand now I can see why :P
22:47:22Araqstupid compiler performing arithmetic with 64 bits
22:48:23Araqmake it seqShallowFlag = low(int) please
22:48:30Araqand see what that echos
22:48:58dom96segfaults with your suggestion above ^^ just FYI
22:49:16Araqit will continue to segfault
22:49:25Araqbut seqShallowFlag is wrong anyway
22:50:45dom96low(int) = -2147483648
22:51:32Araqgood that's much better
22:54:31*Bosc0p quit (Quit: Bosc0p)
22:55:36dom96so when will it not segfault? :P
22:57:07*io2 quit ()
22:57:58Araqfinding bugs in code that is stable on lots of machines is not easy
22:58:23Araqall the obvious bugs have been found already :P
22:58:43VarriountDon't forget the easily fixable ones!
22:58:51dom96Do you have enough info to fix it now?
22:59:11VarriountOr enough info for dom96 to fix it now?
22:59:12Araqlol no way
22:59:40Araqall I can say is: edit lib/system/excpt.nim
22:59:47Araqcut features until it "works"
22:59:56Araqand see what you left out
23:00:03*dom96 sighs
23:00:16Varriountdom96, tis is the life of a programmer.
23:00:19Araqit writes to a 2K buffer
23:00:20dom96Here I thought it was just as simple as changing that flag :\
23:00:41Araqthere is no chance the 2K buffer is not big enough for your stack trace
23:00:47dom96Varriount: It's all worth it in the end ... maybe.
23:00:49Araqso it already never reallocs
23:01:10Araqalso addChar has been tested millions of times
23:01:30Araqetc. etc. it's not easy
23:01:38Araqand I'm sleeping already
23:01:46*ltbarcly quit (Quit: Computer has gone to sleep.)
23:02:00Varriountdom96, just keep this is mind. If you can slay this bug, the path for nimrod support on cellphones is cut that much wider.
23:02:03dom96yeah. We'll pick up where we left off tomorrow.
23:02:18Araqyeah, good night
23:02:25VarriountGood night.
23:02:26dom96Varriount: true
23:02:46*ltbarcly joined #nimrod
23:03:29dom96Varriount: You can try using select manually and seeing if it works.
23:04:06Varriountdom96, Isuspect it's a integer bug
23:04:24VarriountBecause of how nimrod int's aren't 32 bits on win64
23:04:46VarriountThats what caused the last NOTSOCK error
23:04:59dom96nimgrep for "int" then
23:05:19VarriountIt only appears about 1000+ times. :p
23:05:35Varriountpointer, int, integer, int32, etc
23:11:32dom96well have fun
23:11:35dom96I'm away to sleep
23:11:36dom96bye
23:15:52*ltbarcly quit (Quit: Computer has gone to sleep.)
23:17:18*Amrykid quit (Excess Flood)
23:17:49*Amrykid joined #nimrod
23:21:31*silven quit (Ping timeout: 272 seconds)
23:23:52*silven joined #nimrod
23:37:29*BitPuffin joined #nimrod
23:50:40*dsrw joined #nimrod
23:52:47*dsrw quit (Remote host closed the connection)
23:53:30*q66 quit (Quit: Leaving)
23:54:21*dsrw joined #nimrod
23:58:06*dsrw left #nimrod (#nimrod)
23:58:25*dsrw joined #nimrod