--- Log opened Sat Mar 26 00:00:08 2011 --- Day changed Sat Mar 26 2011 00:00 < skelterjohn> an interface is a value typ 00:00 < skelterjohn> e 00:00 < skelterjohn> think of it like a struct { t Type, v Value } 00:00 < skelterjohn> just because v is nil doesn't mean the whole thing is 00:00 < dfr|work> skelterjohn, oh, okay. 00:00 < dfr|work> skelterjohn, yea, I was thinking it would be something like that 00:00 < dfr|work> skelterjohn, is it possible to check whether the actual value is nil? 00:01 < edsrzf> You have to either extract the concrete value from the interface or compare bar to (*Foo)(nil) 00:02 < edsrzf> But if you do the latter and bar is storing (*Baz)(nil), that check will say it's not nil. 00:02 < dfr|work> edsrzf, actually what's going on is that I'm comparing nil to (Foo*)(nil) 00:03 < dfr|work> edsrzf, basically I wrote assertEqual(t, actual, expected interface{}) and when I compare nil against something created from a constructor, I get it that it's not nil when it really is :) 00:03 < dfr|work> so I am trying to figure out how to solve the issue, without having to have a flavor of assertion per each type. 00:03 < skelterjohn> http://pastie.org/1716012 00:03 < skelterjohn> oh 00:04 < skelterjohn> does it make sense to do so? 00:04 < skelterjohn> what if the type is int 00:04 < skelterjohn> how could you check if it was nil? 00:04 < edsrzf> I think gocheck does something like that. 00:04 < skelterjohn> you want to see if the interface contains the nil value for certain types 00:04 < skelterjohn> only makes sense for pointers or other ref types 00:04 < skelterjohn> gocheck? 00:05 < edsrzf> http://goneat.org/pkg/launchpad.net/gocheck/ 00:05 < dfr|work> skelterjohn, actually you may be right. In the sense, that the best the quality check can do is checkign whether memory addresses are the same. 00:05 < edsrzf> Looks like it uses reflection 00:05 < dfr|work> skelterjohn, 'cause there cannot be any other obvious 'equality' 00:06 < edsrzf> It reflects the value and then calls IsNil() 00:06 < skelterjohn> what happens if you do that to an int, edsrzf? 00:06 < edsrzf> You can't because reflect.IntValue doesn't have an IsNil function 00:06 < skelterjohn> i see 00:07 < edsrzf> So you have to make an interface that requires an IsNil method, then see if the reflected value implements that interface. 00:07 < skelterjohn> like edsrzf indicates, it's certainly possible to use reflect to check if it's a pointer type, and then if so, is it nil 00:11 < dfr|work> skelterjohn, yea... but that's a bit too much work for simple scripts I'm doing. 00:11 < dfr|work> skelterjohn, but seems like that framework is building assertions... 00:12 < dfr|work> I currently solved the problem with just doing something like: should(t, "message", func() bool {... }) kind of style 00:12 < dfr|work> that will force it to know the types and not have to cast it to interface{} 00:12 < skelterjohn> no idea what you mean, but that's ok :) 00:12 < dfr|work> skelterjohn, :) 00:13 < dfr|work> skelterjohn, I'm still trying all sorts of different things, so it's all good 00:17 -!- bugQ [~bug@c-67-171-127-76.hsd1.ut.comcast.net] has quit [Ping timeout: 240 seconds] 00:17 < dfr|work> skelterjohn, https://github.com/ratnikov/go-xmpp/blob/master/xmpp_test.go 00:22 -!- m4dh4tt3r [~Adium@213.sub-75-208-177.myvzw.com] has quit [Ping timeout: 250 seconds] 00:27 -!- bugQ [~bug@c-67-171-127-76.hsd1.ut.comcast.net] has joined #go-nuts 00:30 -!- ShadowIce` [~pyoro@unaffiliated/shadowice-x841044] has quit [Quit: Verlassend] 00:33 -!- m4dh4tt3r [~Adium@adsl-75-35-115-144.dsl.pltn13.sbcglobal.net] has joined #go-nuts 00:41 -!- virtualsue [~chatzilla@nat/cisco/x-lyfimpincrrhyovs] has quit [Ping timeout: 248 seconds] 00:42 < ww> ok, i give up for now 00:43 < ww> iant: does libgo really require libstdc++/libiberty? or are the makefiles being overeager 00:46 < ww> it seems like getting this to work means teaching libstdc++ more about arm-android-eabi, which has obviously been done in their patched (4.4.3) but i guess is all but completely undocumented 00:46 -!- tensorpudding [~user@99.148.205.193] has quit [Remote host closed the connection] 00:48 < ww> it should actually not be that hard for someone more familiar with what the different parts of gcc need and want from each other but definitely non-trivial 00:48 < ww> ... non-trivial for me 00:49 < str1ngs> cross compiling is a bitch. on of the reason's I like go so much 00:49 < ww> i can get gccgo to make an object file for the target though, just missing libgo really 00:51 -!- tensorpudding [~user@99.148.205.193] has joined #go-nuts 00:51 < str1ngs> os you have to cross compile libgo no? 00:51 < ww> str1ngs: so the question, which is easier: teach cgo about cross compiling, fixup the missing bits of gcc or coerce a fast arm host into running android (or at least the important bits of it in a chroot) 00:52 < str1ngs> ww: cgo might be easier imo 00:52 < ww> str1ngs: right. which is part of gcc, like libgcc 00:52 < ww> and seems to depend on libstdc++ which hasn't been ported in mainline gcc from what i can tell 00:52 < str1ngs> hard to say do you know exactly how cgo works? thought it wrapped gcc in a fashion 00:53 < ww> i don't know in great detail 00:53 < str1ngs> I'll look at it some more 00:53 < ww> it does run gcc on a generated c file to find out what symbols are needed 00:54 < skelterjohn> cgo = black magic 00:54 < str1ngs> ya my guess is there is no cross feature in cgo it assumes native building 00:54 < ww> that was where i blocked, cgo built for darwin-x86_64 can read elf, but couldn't read the elf that the cross-gcc was making 00:55 < plexdev> http://is.gd/w8Q2ay by [Ian Lance Taylor] in go/test/ -- test: match gccgo error messages for cmp6.go 00:55 < plexdev> http://is.gd/B9V2GZ by [Andrew Gerrand] in go/misc/dashboard/ -- dashboard: remove old python/bash builder, update README 00:56 < str1ngs> ww: checking src/cmd/cgo 00:59 < str1ngs> ww: http://golang.org/cmd/cgo/ 01:01 * ww sleeps 01:01 < str1ngs> ww: as far as I can see its GOARCH aware 01:01 < skelterjohn> str1ngs: what makes you say that 01:02 < skelterjohn> it's aware of the GOARCH you're in at the moment 01:02 < str1ngs> Options prefixed by $GOOS, $GOARCH, or $GOOS/$GOARCH are only defined in matching systems. For example: 01:03 < skelterjohn> that doesn't tell you which GOARCH to use 01:03 < skelterjohn> it says "if you're using this GOARCH, then use this CFLAG/LDFLAG 01:03 < skelterjohn> " 01:03 < ww> actually.... probably far easier 01:03 < ww> tje android scripting stuff, python et al have some sort of socket protocol that proxies api calls... 01:04 < ww> ugly, and you have to run some silly daemon... but much easuer 01:04 < str1ngs> cgo directives can be prefixed by GOOS GOARCH . 01:04 < skelterjohn> i don't know that the makefiles don't do something different depending on $GOARCH and $GOOS, as far as gcc flags go 01:04 < skelterjohn> str1ngs: yes, and i already explained what that meant 01:05 < ww> str1ngs: i tested that, definitely setting GOOS and GOARCH 01:05 < str1ngs> whats the point of prefixing it with anything if you dont plan to target something else? 01:05 < ww> cgo breaks when it tries to extract symbols, see post to list from cgo -dynload 01:05 < skelterjohn> because you can build the same source file on different platforms 01:06 < str1ngs> if thats not cross compiling I dont know what is 01:07 < skelterjohn> ok, that's not cross compiling 01:07 < skelterjohn> cross compiling is building for one platform using a different one 01:07 < skelterjohn> i'm saying that the directives there allow you to build for whichever platform you might want using the same source file 01:07 < skelterjohn> it's like having an #ifdef in a C file that looks at your os 01:07 < str1ngs> ok that makes more sense then 01:08 < skelterjohn> but don't get me wrong - i am not good enough at reading makefiles to say that they don't cross compile w/ cgo 01:08 < skelterjohn> just pointing out that the directives serve a different purpose 01:09 < str1ngs> no thats good . and makes more sense now 01:09 < str1ngs> so really best way to go about this is ignore the makefiles and build by hand 01:09 < str1ngs> have cgo use the target gcc 01:10 -!- binarypie [~binarypie@c-24-6-151-185.hsd1.ca.comcast.net] has quit [Remote host closed the connection] 01:10 < str1ngs> ww: might when to ask if cgo can cross compile on the ML 01:11 < skelterjohn> what options would you give to gcc to make it cross-compile? 01:12 < skelterjohn> i see things in the makefile like _CGO_CFLAGS_386=-m32 01:12 < skelterjohn> but nothing makes me think "cross compile" 01:12 < str1ngs> most of the time when you cross you use configure 01:12 < str1ngs> stuff like --build --host --target 01:13 < skelterjohn> at some level there will be a gcc option =p 01:13 < skelterjohn> or at least an env var 01:13 < str1ngs> with gcc you see the target gcc ie x86_64-unknown-linux-gnu-cc 01:14 < skelterjohn> i didn't understand that at all 01:14 < str1ngs> CC=x86_64-unknown-linux-gnu-cc stuff like that 01:14 < skelterjohn> ah 01:14 < str1ngs> and you have a target linker 01:14 < skelterjohn> so, x86_64-unknown-linux-gnu-cc is a binary somewhere? 01:14 < str1ngs> x86_64-unknown-linux-gnu-ar ld etc 01:14 < str1ngs> right 01:20 -!- rphillips [~rphillips@2001:470:21:31::42dc:59] has quit [Changing host] 01:20 -!- rphillips [~rphillips@unaffiliated/rphillips] has joined #go-nuts 01:21 < str1ngs> skelterjohn: /usr/bin/arm-elf-ld: cannot find crt0.o: No such file or directory the joys of cross compiling 01:22 < str1ngs> I dont know how sane that toolchain is though archlinux package 01:43 < plexdev> http://is.gd/SPu4dJ by [Ian Lance Taylor] in 2 subdirs of go/ -- gc: remove interim ... error which rejects valid code. 02:09 -!- dfc [~dfc@124-149-34-225.dyn.iinet.net.au] has joined #go-nuts 02:29 -!- wrtp [~rog@92.17.50.183] has quit [Quit: wrtp] 02:34 -!- shvntr [~shvntr@116.26.137.93] has joined #go-nuts 02:44 -!- littlebobby [~bob@unaffiliated/littlebobby] has quit [Quit: Ex-Chat] 02:56 -!- dfc [~dfc@124-149-34-225.dyn.iinet.net.au] has quit [Ping timeout: 246 seconds] 03:15 -!- Venom_X [~pjacobs@74.61.90.217] has quit [Quit: Venom_X] 03:36 -!- tokuhiro_ [~tokuhirom@s230.GtokyoFL21.vectant.ne.jp] has joined #go-nuts 03:36 -!- tokuhiro_ [~tokuhirom@s230.GtokyoFL21.vectant.ne.jp] has quit [Client Quit] 03:36 -!- stresstest5880 [foobar@95.69.9.219] has joined #go-nuts 03:39 -!- stresstest5880 [foobar@95.69.9.219] has quit [Remote host closed the connection] 03:42 -!- m4dh4tt3r [~Adium@adsl-75-35-115-144.dsl.pltn13.sbcglobal.net] has quit [Quit: Leaving.] 03:48 < plexdev> http://is.gd/u4gkjx by [Robert Hencke] in go/src/pkg/gob/ -- gob: trivial cleanup 03:56 -!- sysiphus [~opera@unaffiliated/sysiphus] has joined #go-nuts 03:57 -!- keithcascio [~keithcasc@nat/google/x-zdxzasnqlrwukzqm] has quit [Quit: Leaving] 04:02 -!- st-6337 [foobar@95.69.9.219] has joined #go-nuts 04:04 -!- st-6337 [foobar@95.69.9.219] has quit [Remote host closed the connection] 04:08 -!- st-6404 [foobar@95.69.9.219] has joined #go-nuts 04:09 -!- st-6404 [foobar@95.69.9.219] has quit [Read error: Connection reset by peer] 04:10 -!- espeed [~espeed@63.246.231.57] has joined #go-nuts 04:12 -!- rejb [~rejb@unaffiliated/rejb] has quit [Ping timeout: 246 seconds] 04:26 -!- st-6603 [foobar@95.69.9.219] has joined #go-nuts 04:26 -!- sysiphus [~opera@unaffiliated/sysiphus] has quit [Ping timeout: 240 seconds] 04:28 -!- nettok [~quassel@200.119.185.185] has joined #go-nuts 04:30 -!- KingPhilroy [~kingphilr@shc-nat-newhall.stonehill.edu] has quit [Ping timeout: 240 seconds] 04:33 -!- Venom_X [~pjacobs@74.61.90.217] has joined #go-nuts 04:43 -!- KingPhilroy [~kingphilr@204.144.15.20] has joined #go-nuts 04:52 -!- shvntr [~shvntr@116.26.137.93] has quit [Ping timeout: 264 seconds] 04:58 -!- sysiphus [~opera@unaffiliated/sysiphus] has joined #go-nuts 05:01 -!- bugQ [~bug@c-67-171-127-76.hsd1.ut.comcast.net] has quit [Remote host closed the connection] 05:07 -!- sysiphus [~opera@unaffiliated/sysiphus] has quit [Remote host closed the connection] 05:08 -!- sysiphus [~opera@unaffiliated/sysiphus] has joined #go-nuts 05:12 -!- shvntr [~shvntr@116.26.137.93] has joined #go-nuts 05:17 < steven> crap. 05:17 < steven> guys, i just realized a weird go problem 05:18 < jessta> yes? 05:19 < steven> var a interface{}; for _, i := range ints { a, ok := dosomething(i) } // fails 05:20 < steven> if i leave := in there, it says a is created but unused (refering to the inner-loop version), not realizing that its refering to the outer-loop version 05:21 < steven> if i change := to =, it says ok is undefined and cannt be assigned to 05:21 <@adg> steven: just put "var ok bool" on the previous line 05:21 < steven> thats what im currently doing 05:21 < steven> but its an ugly workaround 05:21 < steven> is it the only way? 05:22 < steven> i guess i could solve this with an anonymous function 05:22 < jessta> steven: it's the only way you can remove the ambiguity 05:23 < steven> a := func(){ for _, i := range ints { a, ok := something(i); return a } }() 05:24 < str1ngs> steven: declaring variables is not ugly just need sometimes :P 05:27 < steven> heh 05:28 < jessta> steven: wrapping it in a function seems ugly to me 05:28 < str1ngs> I just will gofmt could handle elastic tabs on := outside of var () 05:28 < str1ngs> wish* 05:29 < jessta> elastic tabs are weird 05:29 < jessta> and kind of crazy 05:29 < str1ngs> I kinda like them. I abuse tabwriter in all console output 05:31 < jessta> the mix of tabs and spaces that gofmt outputs works in all editors 05:32 < str1ngs> ya the while concept of gofmt puts alot of tabs vs spaces to rest 05:33 < str1ngs> one reason I dont like python I dont think tabs should be a syntax 05:33 < skelterjohn> i wonder if it wouldn't be better to separate the : and the = in the :=. so you could say "a:, ok = something()" and it would turn into "var a sometype; a, ok = something()" 05:34 < skelterjohn> but that'd probably be confusing too 05:34 -!- Cobi [~Cobi@2002:1828:88fb:0:aede:48ff:febe:ef03] has joined #go-nuts 05:35 < steven> wait a second 05:36 < steven> the case of the first character of an identifier doesnt control whether that identifier is exported within a struct? 05:36 < skelterjohn> yes it does 05:36 < skelterjohn> unless you have more context in mind than you are sharing 05:37 < steven> i just accessed a.b instead of a.B, from outside one of a's methods 05:37 < skelterjohn> oh 05:37 < skelterjohn> no it's not struct level exporting 05:37 < steven> granted they are in the same package (main) 05:37 < skelterjohn> it's package level 05:37 < skelterjohn> nothing is hidden from within the package 05:37 < str1ngs> steven: if its in the same package you have access to it 05:37 < str1ngs> which is actually nice 05:37 < steven> so if z is a package, and A is a variable (struct), and b is one of its fields, i can still do z.A.b though right? 05:38 < jessta> steven: methods on a type in a package are just functions with sugar 05:38 < skelterjohn> steven: do yourself a favor and don't get in the habit of making "getters" and "setters" with go code 05:38 < str1ngs> steven: if its in the same package you dont need z 05:38 < steven> jessta: i thought they had special access to the unexported methods of the method receiver (assuming its a struct) 05:38 < steven> skelterjohn: im not making a getter or a setter. 05:38 < jessta> steven: nope 05:38 < skelterjohn> the comment about b vs B made me suspicious 05:38 < jessta> they are just functions 05:39 < steven> ok so this will work? somepkg.Somestructvar.somefield ? 05:39 < jessta> no 05:39 < steven> (assuming im not inside of somepkg) 05:39 < skelterjohn> from within or without 05:39 < skelterjohn> then no 05:39 < steven> oh. why not? 05:39 < skelterjohn> because somefield is not exported 05:39 < steven> aaaah. 05:40 < steven> but within somepkg, Somestructvar.somefield works fine 05:40 < str1ngs> yes which is good 05:40 < skelterjohn> nothing is hidden from within 05:40 < steven> i cant find the answer to the first question in the spec anywhere 05:40 < steven> ie, why you cant do somepkg.Somestructvar.somefield 05:40 < str1ngs> it says 05:40 < steven> http://golang.org/doc/go_spec.html#Exported_identifiers looks close, but it doesnt really explain it well 05:40 < skelterjohn> because ... what i just said 05:41 < skelterjohn> somefield is clearly not an exported identifier 05:41 < str1ngs> fields and method with upper can is export lowercase is private 05:41 < skelterjohn> according to that definition 05:41 < steven> yes but i would like to see it explicitly in the spec somewhere that says it applies to structs as well, not just package-level vars/constants/functions/etc 05:41 < skelterjohn> just says identifiers 05:41 < steven> i thought it was just top-level thingies, not structs as well 05:41 < steven> oh 05:41 < skelterjohn> that's all it needs to say 05:41 < steven> so, regardlesss of how deep the level is? 05:42 < steven> (ie structs within structs etc) 05:42 < str1ngs> everything works that way. Functions Structs Fields 05:42 < str1ngs> and Methods 05:42 < steven> ok 05:42 < skelterjohn> identifiers. period. 05:42 < steven> so heres an unrelated question 05:42 < steven> you have a method that either returns a valid interface, or doesnt 05:43 < steven> should it return 1 value, and nil when no valid interface? 05:43 < str1ngs> yes 05:43 < steven> or should it return 2 values, the second being a bool? 05:43 < str1ngs> nil 05:43 < steven> (ie, comma-ok idiom) 05:43 < skelterjohn> i like the comma, ok version 05:43 < steven> why not the latter option? 05:43 < skelterjohn> that is more in line with how the standard library works 05:43 < skelterjohn> and the built-ins 05:43 -!- ExtraSpice [XtraSpice@88.118.35.153] has joined #go-nuts 05:43 < steven> im on the fence, 50/50 05:43 < str1ngs> I guess you can use both. but why force an extra return if you dont need to 05:43 < steven> i can see arguments for both sides 05:44 < str1ngs> I rather have nil, err returned then nil, ok 05:44 < steven> only reason im 51% in favor for the comma-ok is that for some reason, nil might be a valid return value for the interface 05:44 < steven> though i cant possibly imagine that ever happening in my specific situation... 05:44 < steven> but it doesnt mean it wont ever be true in the future 05:44 < str1ngs> it varies I guess 05:44 < skelterjohn> well, it pretty much does, in most cases :) 05:45 < skelterjohn> but that's another issue 05:45 < steven> hehe 05:45 < str1ngs> I'm lazy so I use nil :P 05:45 < steven> heh. 05:45 < jessta> steven: nil isn't a useful value for a interface 05:46 < skelterjohn> sure it is 05:46 < steven> im type-switching on it, it might be valid for that purpose 05:46 < skelterjohn> os.Errors are often nil 05:46 < steven> thats not the same point skelterjohn 05:46 < skelterjohn> responding to jessta 05:46 < steven> thats arguing against comma-ok ;) 05:46 < skelterjohn> no, it's arguing for 05:46 < steven> by accident :) 05:46 < skelterjohn> if nil is valid, then you need to do ,ok 05:47 < steven> no, because analogously, when err == nil, it means an absence of an error 05:47 < skelterjohn> i'm saying that nil is valid for interfaces, especially with the os.Error example 05:47 < steven> whch would argue for the single-return-value rather than comma-ok in this case ;) 05:47 < skelterjohn> func GetTheErrorThatHappened() (err os.Error, ok bool) 05:47 < steven> oooh 05:47 < skelterjohn> sometimes the function fails 05:47 < steven> yeah, i getcha now. 05:48 < skelterjohn> or it doesn't block 05:48 < steven> anyway gonna go read more about git.. i wanna learn enough of it to write an implementation in Go and license it BSD-style :D 05:48 < skelterjohn> oy 05:48 < skelterjohn> you pick your projects strangely 05:48 < steven> probably. 05:48 < steven> im weird. 05:48 < jessta> skelterjohn: but you can't call methods on a nil interface 05:48 < skelterjohn> what happened to your go-rails proj? 05:49 < steven> skelterjohn: its on hold until i learn more about git. 05:49 < dforsyth> anyone have draw working on os x? 05:49 < steven> we do some git stuff at work that i dont really understand sometimes, so i need to get more familiar with it 05:49 < str1ngs> steven: I'm already working on libgit2 bindings .. if you want to help 05:49 < steven> this is one way of going about that 05:49 < skelterjohn> dforsyth: i have used x11 on os x to draw stuff 05:49 < steven> str1ngs: thanks but this way sounds more fun :) 05:49 < dforsyth> skelterjohn: i get "unsupported Xauth" when i go x11.NewWindow 05:49 < steven> dforsyth: i have but i deleted the example 05:49 < skelterjohn> dforsyth: it's a bit limited...you can't, for instance, resize your window 05:49 < dforsyth> ever run into that? 05:49 < steven> its really easy dforsyth 05:50 < steven> dforsyth: you have to have X11 running in the backround first 05:50 < skelterjohn> dforsyth: yes i did. do you tell your terminal to treat a non-standard directory as home? 05:50 < skelterjohn> steven: no you don't 05:50 < skelterjohn> it will launch 05:50 < str1ngs> steven: well that's abit harsh no? 05:51 < dforsyth> dforsyth$ echo $HOME 05:51 < dforsyth> /Users/dforsyth 05:51 < skelterjohn> I told mine to use /Users/me/Documents for a while, and that really messed it up 05:51 < skelterjohn> do you have a ~/.Xauthority file? 05:52 < dforsyth> i do 05:52 < dforsyth> xauth list shows entries 05:52 < skelterjohn> ok, well that about brings me to the limit of my x11+go debugging tricks 05:52 < steven> btw guys, 05:52 < skelterjohn> unfortunately 05:52 < dforsyth> lol 05:52 < skelterjohn> can you run x11 apps otherwise with no trouble? 05:52 < steven> listen: http://www.youtube.com/watch?v=BjMiDZIY1bM 05:53 < dforsyth> yeah i can open an xterm 05:53 < str1ngs> steven: I'm still confused why you just side stepped my project? 05:53 < str1ngs> actually I'm confuses why alot of go projects do that 05:53 < dforsyth> weird 05:54 < skelterjohn> str1ngs: he stated he wanted to do it to learn git 05:54 < skelterjohn> so collaboration is less important, since the goal is not to make a working product 05:54 < str1ngs> skelterjohn: and you think thats some small task? why do you think I'm using libgit2 as a stop gap. which I already said I hope would lead to native bindings 05:55 < steven> str1ngs: i thought i explained that yesterday? 05:55 < skelterjohn> i don't know how that contradicts what i said 05:55 < skelterjohn> i can only assume it does somehow from the tone of the comment 05:55 < steven> i want to implement git entirely in Go 05:55 < str1ngs> yes which is common to my goal 05:55 < steven> i want to do it from scratch, avoiding C 05:55 < str1ngs> but its not an easy task. 05:56 < steven> i dont know that. it might actually be. 05:56 < steven> at least, not every feature, but the basic concepts 05:56 < skelterjohn> afterall, if linus torvald can do it, anyone can 05:56 < dforsyth> lol 05:56 < dforsyth> damn you, draw pkg 05:56 < steven> <3 05:57 < skelterjohn> dforsyth: draw/x11 is really lame, anyway 05:57 < skelterjohn> you're not missing anything 05:57 < dforsyth> skelterjohn: i literally just wanted to paint a series of jpegs on the screen 05:57 < skelterjohn> i know the feeling 05:58 < skelterjohn> i wish i knew how to help better 05:58 < dforsyth> installing sdl on my mac is a bigger pain in teh balls than it should be 05:58 < dforsyth> meh, no biggy 05:59 < str1ngs> dforsyth: use does it have to be draw can you use xdg instead maybe? 05:59 < steven> dforsyth: ive used draw very easily 05:59 < steven> im not sure why you're running into so much trouble. 05:59 < steven> why is it btw that you can only get gcc through Xcode? 05:59 < dforsyth> str1ngs: does that have decode and simple drawing? im not in the mood to think too much about it 06:00 < str1ngs> dforsyth: it has simpel drawing yes, define decode 06:00 < dforsyth> decoding jpeg 06:00 < dforsyth> well i guess that package works 06:00 < dforsyth> nvm, brain fart 06:00 < dforsyth> ill look at xdg 06:00 < dforsyth> ty 06:00 < str1ngs> dforsyth: I've done some stuff with it just messing around really 06:01 -!- nettok [~quassel@200.119.185.185] has quit [Ping timeout: 240 seconds] 06:01 -!- araujo [~araujo@gentoo/developer/araujo] has quit [Quit: Leaving] 06:02 -!- nettok [~quassel@200.119.185.185] has joined #go-nuts 06:03 -!- sysiphus [~opera@unaffiliated/sysiphus] has quit [Ping timeout: 240 seconds] 06:09 < dforsyth> i want to roll some native lib 06:09 < dforsyth> s 06:09 < str1ngs> of ? 06:10 < dforsyth> i havent thought that far ahead yet 06:10 < str1ngs> I need a compression lib. that can handles tar.gz's and tar.bz 06:10 < str1ngs> everything is in the stdlib just need to be put to gether 06:10 < dforsyth> most fo what ive done for the past few years has been on a package library, but i want to stop working on that 06:11 < dforsyth> thea archive stuff in stdlib doesnt handle compression? 06:11 < str1ngs> its does but its low level 06:11 < str1ngs> I'm going to write it eventually 06:11 < dforsyth> its libarchive, right? 06:12 < str1ngs> something like that 06:12 < dforsyth> that is a complex lib 06:12 < str1ngs> doenst need to be fancy pass a file and dest kinda thing 06:12 < str1ngs> as far as I can see everthing is in the stdlib 06:14 < dforsyth> i see 06:14 < str1ngs> I'm just giving you ideas :P 06:14 < dforsyth> :) 06:14 < str1ngs> if you like network stuff there gurl which I'm useing for basic libcurl stuff 06:15 < str1ngs> its reall crud right now 06:15 < dforsyth> when i met griesemer he suggested ui toolkit stuff 06:15 < dforsyth> i dont really feel like doing that though 06:15 < str1ngs> ya thats not easy 06:16 < dforsyth> what is gurl? link? 06:16 < dforsyth> nvm its in your github 06:17 < str1ngs> it need tls http header keep alive etc 06:17 < str1ngs> eventually ftp 06:17 < str1ngs> also callbacks for transfer rates 06:19 < str1ngs> I'm using it in one project, so I figure I just piece meal it as I go along 06:19 -!- alkavan [~alkavan@IGLD-84-229-243-69.inter.net.il] has joined #go-nuts 06:22 -!- photron [~photron@port-92-201-123-16.dynamic.qsc.de] has joined #go-nuts 06:30 < steven> <3 06:30 < steven> str1ngs: i hope you arent upset about me and the git thing 06:30 < steven> you seemed upset 06:33 < str1ngs> I'm not upset just confused 06:33 < steven> :/ 06:34 < str1ngs> I have real need for a go git api. and I think others do too. would make sense to work together 06:34 < str1ngs> if you just plan on making something for fun .. ok I understand. 06:36 < str1ngs> however I think a native api is better if you plan to see it through. I can put this aside 06:37 < steven> im not entirely sure i have the ability to see it through 06:38 < steven> thats one of the reasons im not committing to anything more than a side project for this git thing 06:38 < steven> since im not sure of my abilities of understanding git well enough yet 06:38 < str1ngs> aye neither do I hence why I though libgit2 would be a good start 06:38 < steven> right 06:38 < steven> sorry 06:38 < str1ngs> leading to a native api 06:40 -!- nsf [~nsf@jiss.convex.ru] has joined #go-nuts 06:40 < str1ngs> cgit useins libgit.a which is an internal libary that git.git uses. but its not really a api, you need to know the internal workings of git.git 06:41 < str1ngs> libgit2 takes it a steps farther. higher api well documented 06:41 < str1ngs> the go to libgit2 is pretty easy. hard for me simple because I'm not a C programmer 06:42 < str1ngs> now to write it in go... I have no clue where you would start. 06:45 < str1ngs> honest you'll probably learn more about git working with the libgit2 in a short period of time 06:45 < dforsyth> is possible to map[interface{}]type ? 06:46 -!- nettok [~quassel@200.119.185.185] has quit [Ping timeout: 240 seconds] 06:47 < str1ngs> if it has equality I dont think interface{} would work 06:47 < dforsyth> well im more interested in teh type part 06:47 < dforsyth> i mean the keyword type 06:48 < dforsyth> it didnt work when i tried ot compile it, just wondering if its possible some how 06:48 < str1ngs> ah sorry. ya that could work check :P 06:55 -!- preflex [~preflex@unaffiliated/mauke/bot/preflex] has quit [Read error: Operation timed out] 06:55 -!- sysiphus [~opera@unaffiliated/sysiphus] has joined #go-nuts 06:56 -!- tensorpudding [~user@99.148.205.193] has quit [Read error: Connection reset by peer] 06:57 -!- st-6603 [foobar@95.69.9.219] has quit [Remote host closed the connection] 06:58 -!- aho [~nya@fuld-590c71a8.pool.mediaWays.net] has quit [Quit: EXEC_over.METHOD_SUBLIMATION] 07:00 -!- Venom_X [~pjacobs@74.61.90.217] has quit [Quit: Venom_X] 07:01 -!- preflex [~preflex@unaffiliated/mauke/bot/preflex] has joined #go-nuts 07:04 -!- st-8688 [foobar@95.69.9.219] has joined #go-nuts 07:09 -!- st-8688 [foobar@95.69.9.219] has quit [Read error: Connection reset by peer] 07:13 -!- st-8806 [foobar@95.69.9.219] has joined #go-nuts 07:20 < steven> oh cool i just learned how git shas are created for a single file. 07:21 -!- tokuhiro_ [~tokuhirom@s230.GtokyoFL21.vectant.ne.jp] has joined #go-nuts 07:29 -!- |Craig| [~|Craig|@panda3d/entropy] has quit [Quit: |Craig|] 07:30 < steven> https://gist.github.com/888103 07:33 < steven> woot :) 07:38 < str1ngs> git doesnt work on single files though :P 07:38 < str1ngs> but its a start! 07:40 -!- araujo [~araujo@gentoo/developer/araujo] has joined #go-nuts 07:40 -!- sysiphus [~opera@unaffiliated/sysiphus] has quit [Ping timeout: 246 seconds] 07:41 < steven> whoa 07:41 < steven> i think i get something 07:42 < steven> nm. 07:43 < steven> im reading git from the bottom up, and its pretty awesome so far 07:44 < steven> <3 07:52 -!- dahankzter [~henrik@92-244-3-192.customers.ownit.se] has joined #go-nuts 07:52 -!- sysiphus [~opera@unaffiliated/sysiphus] has joined #go-nuts 07:53 -!- alkavan [~alkavan@IGLD-84-229-243-69.inter.net.il] has quit [Quit: Leaving] 07:57 -!- skejoe [~skejoe@188.114.142.162] has joined #go-nuts 07:59 -!- st-8806 [foobar@95.69.9.219] has quit [Remote host closed the connection] 08:00 -!- dahankzter1 [~henrik@92-244-3-192.customers.ownit.se] has joined #go-nuts 08:01 -!- dahankzter [~henrik@92-244-3-192.customers.ownit.se] has quit [Ping timeout: 246 seconds] 08:08 -!- rlab [~Miranda@91.200.158.34] has joined #go-nuts 08:10 -!- piranha [~piranha@5ED42E59.cm-7-5a.dynamic.ziggo.nl] has joined #go-nuts 08:18 -!- nixness [~dsc@SMSADLER.WV.QATAR.CMU.EDU] has joined #go-nuts 08:18 -!- sysiphus [~opera@unaffiliated/sysiphus] has quit [Ping timeout: 276 seconds] 08:35 < str1ngs> anyone else get this output from gofmt 08:35 < str1ngs> -r="": rewrite rule (e.g., '??[??:len(??)] -> ??[??:]') 08:35 < str1ngs> grr I'll pastebin. looks like a unicode issue 08:39 < str1ngs> https://gist.github.com/888137 08:46 -!- rlab_ [~Miranda@91.200.158.34] has joined #go-nuts 08:47 -!- rlab [~Miranda@91.200.158.34] has quit [Ping timeout: 250 seconds] 08:47 < str1ngs> hmm must be my terminal font. 09:03 -!- pingveno [~pingveno@c-98-246-133-8.hsd1.or.comcast.net] has quit [Max SendQ exceeded] 09:03 -!- stalled [~stalled@unaffiliated/stalled] has quit [Max SendQ exceeded] 09:03 -!- pingveno [~pingveno@c-98-246-133-8.hsd1.or.comcast.net] has joined #go-nuts 09:04 -!- pingveno [~pingveno@c-98-246-133-8.hsd1.or.comcast.net] has quit [Max SendQ exceeded] 09:04 -!- Soultaker [~Soultaker@hell.student.utwente.nl] has quit [Max SendQ exceeded] 09:04 -!- Soultaker [~Soultaker@hell.student.utwente.nl] has joined #go-nuts 09:07 -!- Soultaker [~Soultaker@hell.student.utwente.nl] has quit [Max SendQ exceeded] 09:08 -!- jessta_ [~jessta@li7-205.members.linode.com] has joined #go-nuts 09:08 -!- i___ [~none@69.164.206.224] has joined #go-nuts 09:08 -!- ShadowIce [~pyoro@HSI-KBW-109-193-120-162.hsi7.kabel-badenwuerttemberg.de] has joined #go-nuts 09:09 -!- ShadowIce [~pyoro@HSI-KBW-109-193-120-162.hsi7.kabel-badenwuerttemberg.de] has quit [Changing host] 09:09 -!- ShadowIce [~pyoro@unaffiliated/shadowice-x841044] has joined #go-nuts 09:09 -!- j3parker_ [j3parker@artificial-flavours.csclub.uwaterloo.ca] has joined #go-nuts 09:09 -!- Soultaker [~Soultaker@hell.student.utwente.nl] has joined #go-nuts 09:09 -!- d_m_ [d6@SDF.ORG] has joined #go-nuts 09:10 -!- pingveno [~pingveno@c-98-246-133-8.hsd1.or.comcast.net] has joined #go-nuts 09:12 -!- tylergillies [~quassel@unaffiliated/tylergillies] has quit [Max SendQ exceeded] 09:12 -!- niekie [~niek@CAcert/Assurer/niekie] has quit [Max SendQ exceeded] 09:12 -!- Cobi [~Cobi@2002:1828:88fb:0:aede:48ff:febe:ef03] has quit [Max SendQ exceeded] 09:12 -!- napsy [~luka@tm.213.143.73.175.lc.telemach.net] has quit [Quit: Lost terminal] 09:12 -!- stalled [~stalled@unaffiliated/stalled] has joined #go-nuts 09:13 -!- Netsplit *.net <-> *.split quits: ccount, d_m, jessta, j3parker, i__ 09:13 -!- tylergillies [~quassel@204-232-205-180.static.cloud-ips.com] has joined #go-nuts 09:13 -!- tylergillies [~quassel@204-232-205-180.static.cloud-ips.com] has quit [Changing host] 09:13 -!- tylergillies [~quassel@unaffiliated/tylergillies] has joined #go-nuts 09:15 -!- Cobi [~Cobi@2002:1828:88fb:0:aede:48ff:febe:ef03] has joined #go-nuts 09:16 -!- niekie [~niek@CAcert/Assurer/niekie] has joined #go-nuts 09:17 -!- st-2451 [~st-2451@a89-154-147-132.cpe.netcabo.pt] has joined #go-nuts 09:21 -!- ccount [~ccount@aleph0.de] has joined #go-nuts 09:32 -!- shvntr [~shvntr@116.26.137.93] has quit [Ping timeout: 250 seconds] 09:35 -!- virtualsue [~chatzilla@nat/cisco/x-annijnwpdogwwxvy] has joined #go-nuts 09:42 -!- bortzmeyer [~stephane@2a01:e35:8bd9:8bb0:ecb8:91b8:365d:1c0e] has joined #go-nuts 09:43 -!- shvntr [~shvntr@119.121.55.178] has joined #go-nuts 10:03 -!- Project_2501 [~Marvin@82.84.93.120] has joined #go-nuts 10:10 -!- ronnyy [~quassel@p4FF1C221.dip0.t-ipconnect.de] has joined #go-nuts 10:15 -!- dahankzter1 [~henrik@92-244-3-192.customers.ownit.se] has quit [Ping timeout: 250 seconds] 10:42 -!- piranha [~piranha@5ED42E59.cm-7-5a.dynamic.ziggo.nl] has quit [Quit: Computer has gone to sleep.] 10:48 -!- nixness [~dsc@SMSADLER.WV.QATAR.CMU.EDU] has quit [Remote host closed the connection] 10:52 -!- sauerbraten [~sauerbrat@p508CAA66.dip.t-dialin.net] has joined #go-nuts 10:52 -!- tensai_cirno [~cirno@77.232.15.216] has joined #go-nuts 10:53 -!- Fish- [~Fish@bus77-2-82-244-150-190.fbx.proxad.net] has joined #go-nuts 10:57 -!- dahankzter [~henrik@92-244-3-192.customers.ownit.se] has joined #go-nuts 11:02 -!- boscop [~boscop@g230099063.adsl.alicedsl.de] has joined #go-nuts 11:08 -!- piranha [~piranha@5ED43A0B.cm-7-5a.dynamic.ziggo.nl] has joined #go-nuts 11:16 -!- Project_2501 [~Marvin@82.84.93.120] has quit [Quit: E se abbasso questa leva che succ...] 11:28 -!- edsrzf [~chickench@122-61-221-144.jetstream.xtra.co.nz] has quit [Remote host closed the connection] 11:31 -!- KingPhilroy [~kingphilr@204.144.15.20] has quit [Quit: Sleeping with the fishes...] 11:42 -!- wrtp [~rog@92.17.50.183] has joined #go-nuts 11:51 -!- piranha [~piranha@5ED43A0B.cm-7-5a.dynamic.ziggo.nl] has quit [Quit: Computer has gone to sleep.] 11:59 < taruti> Is there an elegant solution for having multiple go-installations with separate GOROOTs and PATHs in concurrent use? (mainly crosscompiling for a different os) 12:00 < str1ngs> taruti: for gc all you should need to do is change GOOS and GOARCH 12:00 < str1ngs> only problem i had was with cgo 12:01 < taruti> str1ngs: and GOROOT probably? 12:01 < str1ngs> what I would do is have a arm x86 shell script and just source them with those enviroment vars when you need to build 12:01 < str1ngs> taruti: GOROOT can stay 12:02 < str1ngs> cgo if you need it might need a differect GOBIN though.. not sure 12:04 -!- ExtraSpice [XtraSpice@88.118.35.153] has quit [Ping timeout: 276 seconds] 12:07 -!- espeed [~espeed@63.246.231.57] has quit [Remote host closed the connection] 12:07 -!- zimsim [~simon@87.72.77.195] has joined #go-nuts 12:11 < zimsim> that strings api is somewhat confusing for someone who doesn't know the difference of Title and Upper case. Someone care to explain? 12:13 < taruti> "This Is Title Case" "UPPERCASE" 12:13 < zimsim> What I'm asking about is: What is the difference of strings.ToUpper and strings.ToTitle. 12:13 < zimsim> right, you got it wrong as well 12:13 < zimsim> just like i did 12:13 < taruti> hmm? 12:13 < taruti> it was some unicode weirdness? 12:13 < zimsim> ToTitle returns a UPPER CASE string 12:14 < zimsim> while Title returns a Title Case String 12:14 < zimsim> where is Rob Pike when we need him? 12:14 < zimsim> :p 12:15 <@adg> i think this is a bug 12:15 <@adg> hmm or maybe not 12:15 < str1ngs> adg: gofmt ? 12:15 <@adg> no the Title/ToTitle distinction 12:15 < str1ngs> ah ok 12:16 -!- skejoe [~skejoe@188.114.142.162] has quit [Quit: Lost terminal] 12:17 <@adg> str1ngs: i don't know about that gofmt issue 12:17 <@adg> i get -r="": rewrite rule (e.g., '?[?:len(?)] -> ?[?:]') 12:17 <@adg> where the ?'s are alpha and beta symbols 12:19 -!- ExtraSpice [XtraSpice@88.118.35.153] has joined #go-nuts 12:20 < zimsim> Poking around in $GOROOT/src/pkg/unicode/letter_test.go and from the looks of it ToTitle and ToUpper are expected to behave exctly the same. 12:22 < zimsim> Furthermore its inconsistent how strings.Title is a function name, since all the other case manipulating funcs have `To` prefix 12:25 < exch> There is a ToTitle as well 12:26 -!- huin [~huin@91.85.185.181] has joined #go-nuts 12:26 <@adg> zimsim: they do behave differently for some characters 12:26 <@adg> zimsim: see the definitions in the last declaration of this file http://golang.org/src/pkg/unicode/tables.go 12:27 < skelterjohn> morning 12:27 <@adg> the first and last elements of the type d describe where upper and title case ends respectively 12:27 -!- rtharper [~tomh@unaffiliated/sioraiocht] has quit [Read error: Connection reset by peer] 12:28 <@adg> zimsim: so for most purposes, they're the same, but i guess for some specific characters it's different 12:28 < str1ngs> adg: its fine in gedit, just not in urxvt or gnome-terminal. so might be some font issue 12:28 -!- rtharper [~tomh@unaffiliated/sioraiocht] has joined #go-nuts 12:28 <@adg> zimsim: i think the naming is consistent, when you consider that the ToX functions convert each character in the string to case X 12:29 <@adg> zimsim: where Title does something distinctly different 12:29 < zimsim> adg: thanks for clearing that up. I somewhat expected this having to do with the world of unicode which is somewhat outside my range of knowledge 12:30 <@adg> also "Title case" is different to a title 12:30 <@adg> wikipedia: "Title case ? All words are capitalized except for certain subsets defined by rules that are not universally standardized." 12:30 <@adg> so it's not what i thought it would be 12:31 <@adg> zimsim: thanks for asking an interesting question, i've learned something too ) 12:31 <@adg> ;) 12:35 < skelterjohn> http://developers.slashdot.org/story/11/03/26/0016229/CMU-Eliminates-Object-Oriented-Programming-For-Freshman 12:35 < skelterjohn> a good start! 12:35 < zimsim> np. Still think many will mistaken the two functions. You've proven that the distinction is clean from a technical point of view, but I haven't seen it used before. And I dont think its very common either 12:38 < nsf> anti-modular? 12:38 < nsf> wtf 12:46 < skelterjohn> your face is anti-modular 12:46 < aiju> your mom is anti-modular 12:52 < xyproto> objects are often more like... cars than a set of parts, easy to be reused by other cars, though (and every good anology is just like a car...) 12:56 < skelterjohn> every good analogy is like a car - people only die when you start using it? 12:56 < xyproto> skelterjohn: something like that ;) 12:57 < xyproto> I'm trying to find the source code for the make() function, btw. Where in the go source tree is it located? 12:57 < xyproto> I've tried searching and googling, several times. 13:00 < skelterjohn> runtime 13:01 < xyproto> skelterjohn: thanks 13:03 -!- foocraft [~dsc@78.100.171.45] has quit [Ping timeout: 255 seconds] 13:14 -!- femtoo [~femto@95-89-249-242-dynip.superkabel.de] has joined #go-nuts 13:15 -!- dahankzter [~henrik@92-244-3-192.customers.ownit.se] has quit [Read error: Connection reset by peer] 13:37 -!- waqas [~waqas@jaim.at] has joined #go-nuts 13:41 < xyproto> I think it was surprising that make() can be called like this: make(chan string,) 13:41 < xyproto> If I want to create a function that can be called the same way in Go, how is it done? 13:41 < nsf> all functions can be called like this 13:41 < nsf> all 1 argument functions 13:41 < nsf> it's the same as: 13:41 < nsf> make(chan string) 13:42 < xyproto> nsf: oh, okay. But, why is it not a syntax error to include the extra comma? 13:42 < nsf> god knows why 13:42 < nsf> but there is an optional comma in the syntax 13:42 < xyproto> I see :) 13:43 < xyproto> But, when defining maps with {}, the last comma is not optional, right? 13:43 < xyproto> (for a list of elements within {} ) 13:43 < nsf> there is an optional comma too 13:43 < nsf> it's everywhere :) 13:43 < nsf> e.g. []int{1, 2, 3,} 13:43 < nsf> is valid 13:44 < nsf> but in that case there is a purpose 13:44 < nsf> to defeat automatic semicolon insertion 13:44 -!- rejb [~rejb@unaffiliated/rejb] has joined #go-nuts 13:44 < nsf> []int{ 13:44 < nsf> 1, 13:44 < nsf> 2, 13:44 < nsf> 3, 13:44 < nsf> } 13:44 < nsf> all ok ) 13:44 < nsf> otherwise after '3' there will be an inserted semicolon 13:44 < xyproto> nsf: I have an example where it is not ok 13:45 < nsf> :\ 13:45 < nsf> show me 13:45 < xyproto> http://go.pastie.org/1717944 13:45 < xyproto> That code will not compile without a , after "fjos" 13:45 < Namegduf> I heard that "show me2 in Morpheus's voice from the original Matrix movie. 13:45 < aiju> yeah 13:46 < aiju> xyproto: because of semicolon insertion 13:46 < aiju> , is necessary at the end of a line 13:46 < nsf> xyproto: but that's what I'm saying 13:46 < aiju> yeah 13:46 < nsf> optional semicolon in compound statement actually has purpose 13:46 < Namegduf> xyproto: Go permits trailing commas anyway, it makes your life easier anyway. 13:46 < nsf> for that kind of things 13:46 < xyproto> nsf: okay, so what you're saying is that commas are optional or not? 13:46 < nsf> they are 13:46 < xyproto> nsf: not in my example? 13:47 < Namegduf> xyproto: Trailing commas are optional, but you need one if you want to put the closing brakcet on another line 13:47 < nsf> s := map[string]string{"1":"1", "2":"2",} 13:47 < Namegduf> Simple as that 13:47 < nsf> it works 13:47 < nsf> xyproto: SEMICOLON INSERTION 13:47 < xyproto> aha! now it dawned on me :D 13:47 < xyproto> okay, so it's only cases where } is on the next line that , behaves differently 13:48 < nsf> it doesn't 13:48 < Namegduf> , suppresses an automatic semicolon 13:48 < nsf> :\ 13:48 < xyproto> oO 13:48 < nsf> yeah 13:48 < nsf> there is a fucking imaginary semicolon 13:48 < Namegduf> You can ALWAYS have an extra , 13:48 < nsf> :) 13:48 < Namegduf> If you want to suppress the imaginary semicolon, you MUST have it 13:48 < nsf> yeah 13:48 < Namegduf> There is no case where you can't have it 13:48 < xyproto> ok 13:49 < xyproto> can , be used to surpress an imaginary semicolon after a function signature and before the opening { as well? 13:49 < Namegduf> No, because , is not syntactically correct there. 13:49 < xyproto> this whole , and imaginary semicolon business is not consistant at all! 13:49 < Namegduf> It's perfectly consistent. 13:49 < aiju> xyproto: it is totally consistent 13:49 < nsf> xyproto: join alexandrescu 13:49 < nsf> he doesn't like that as well 13:49 < Namegduf> , separates list items, right? 13:50 < Namegduf> You're also allowed to include one after the last list item. 13:50 < xyproto> Namegduf: yes, except when it may trail a function argument and/or surpress an imaginary semicolon 13:50 < nsf> xyproto: read about rules for semicolon insertion 13:50 < Namegduf> No, it can't. 13:50 < nsf> they are very simple 13:50 < Namegduf> xyproto: That's not a special rule. 13:50 < xyproto> If I wanted to relate to semicolons, I would write in a language that is honest about them. 13:51 < Namegduf> It separates list items and function parameters. You're also allowed to include one after the last item in such a list, in order to make moving them around easier if each is on its own line 13:51 < xyproto> I don't like it. *grumps* 13:51 < Namegduf> This has a SIDE EFFECT of suppressing automatic semicolons after the last entry 13:51 < Namegduf> Because it can't happen after a comma in the middle of a list, and thus can't happen after one at the end, either 13:52 < Namegduf> It's just what happens when you put the trailing-comma-is-allowed rule together with semicolon insertation rules, which include "semicolons won't be inserted after colons because that breaks lists of things over multiple lines" 13:53 < xyproto> Ok, thanks nsf, aiju and Namegduf. I agree that it is consistent, in its implementation. I will meditate on the meaning of this. 13:53 < xyproto> :) 13:53 < Namegduf> I'm willing to agree that it's a tad voodoo. 13:53 < Namegduf> I really wish it was a bit smarter, really. 13:53 < Namegduf> The problem is the time for smartness is not during lexing 13:53 < aiju> making it smarter would it make worse, probably 13:53 < Namegduf> Which is when they're magically added 13:53 < aiju> *make it 13:54 < Namegduf> aiju: Well, it's obvious that inserting a semicolon between the start and end of a list or set of function arguments is wrong 13:54 < aiju> how do other languages handle this, after all? 13:54 < Namegduf> Horribly 13:54 < Namegduf> JS inserts semicolons when not having them causes a syntax error 13:54 < aiju> Python et al. 13:54 < aiju> JS does it *really* crappy 13:55 < nsf> in python \n is part of the syntax afaik 13:55 < huin> it is 13:55 < Namegduf> Yeah. 13:55 < huin> you have to specifically continue the line with a trailing \ or having unbalanced brackets 13:55 < huin> un*closed*, i should say 13:55 < Namegduf> If Go treated \n as a proper part of the syntax 13:56 < Namegduf> It could have that unclosed bracket rule 13:56 < Namegduf> And that would make cases like this much nicer, as well as permit \n inside brackets to count as , 13:56 < Namegduf> But doing that in the lexer would be wrong, I think 13:56 < Namegduf> And that's where the semicolon insertation magic happens. 13:57 < xyproto> Why can't ",\n}" be stripped of newlines and just being considered as a "}"? 13:57 < Namegduf> Because it doesn't need to be because trailing commas are always legal anyway? 13:57 < xyproto> the other way around, then 13:58 < Namegduf> You mean "\n}" be treated as "}"? 13:58 < xyproto> no, } being treated as ,} 13:58 < Namegduf> ...it is? 13:58 < Namegduf> ,} == } in behaviour 13:58 < xyproto> "\n}" is not being treated as ",\n}" 13:58 < Namegduf> No, it isn't. 13:58 < Namegduf> But that's a separate issue. 13:59 < Namegduf> ,\n} is treated as } 13:59 < aiju> xyproto: currently, the grammar doesn't see the \n 13:59 < aiju> the grammar sees ";}", which is illegal 13:59 < nsf> maybe it's possible to do that using lexical lookahead? 13:59 < Namegduf> So yes, the question is why \n} can't be lexer-hacked to be equivalent to } 13:59 < Namegduf> And it COULD be, but that would be neither consistent nor orthagonal 13:59 < Namegduf> It'd be a special case rule 13:59 < aiju> i mean, come on 13:59 < Namegduf> Just use a damn trailing comma 13:59 < aiju> does it hurt that much to place that comma? 14:00 < Namegduf> Trailing commas being mandatory in nice multiline lists of things is no bad thing because they're better anyway 14:00 < xyproto> what if all } were replaced with ",}" ? 14:00 < Namegduf> \n,} would be wrong. 14:00 < Namegduf> It'd result in the same error as \n} 14:01 < Namegduf> } to ,} and ,} to } does precisely crap all 14:01 < xyproto> aiju: no, it does not, I just got a feeling that the whole , semicolon {} thing is the main (only?) thing that the Go syntax has got wrong, in my personal opinion. 14:02 < Namegduf> Go inserts semicolons at the end of lines except where they end in something that would make it obviously illegal, like a comma. 14:02 < jessta_> xyproto: the rules for semicolon insertion are fairly simple 14:02 < Namegduf> Trailing commas are allowed so it's easier to switch lines around. 14:02 < Namegduf> Those are nice and simple 14:02 < Namegduf> Your ideas involve special case hacks which accomplish little or nothing 14:02 -!- piranha [~piranha@brmn-4dbcdbda.pool.mediaWays.net] has joined #go-nuts 14:02 < xyproto> Namegduf: no, there must be a better way somehow 14:02 < Namegduf> You can't write \n before the comma, because that'd cause a semicolon insertation 14:03 < xyproto> jessta_: yes, I agree 14:03 < Namegduf> xyproto: The options which might be better are "Make \n a full, proper part of the syntax" and "explicit semicolons" 14:03 < jessta_> xyproto: you get used to them very quickly and then it's not a problem 14:04 < jessta_> xyproto: not having to add semicolons is really nice 14:04 -!- piranha [~piranha@brmn-4dbcdbda.pool.mediaWays.net] has quit [Client Quit] 14:04 < Namegduf> The only other option which gets full optional semicolon-ness behaviour either involves very complex lexer hacks to special case everything 14:04 < nsf> but some people hate it 14:04 < nsf> :D 14:04 < Namegduf> Or JS behaviour 14:04 < xyproto> Namegduf: "the only other option" are strong words 14:04 < aiju> JS behaviour is JUST WRONG 14:04 < Namegduf> xyproto: They're also valid, I think. 14:04 < aiju> JS behaviour is completely unpredictable 14:04 < jessta_> xyproto: there are not other options that don't require look ahead 14:04 < Namegduf> The behaviour you want requires knowledge of the language's syntax. 14:05 < Namegduf> That means either \n must be handled at the level that information is available, or your lexer must have all those syntactical rules in it. 14:05 < xyproto> Namegduf: as you probably know, you can't prove non-existance. "There are no other options" can't be valid, only an opinion, in this connection. 14:05 < Namegduf> Um 14:05 < Namegduf> Wrong. 14:05 < xyproto> Namegduf: why? 14:06 < Namegduf> I can prove that claim wrong by counterexample. 14:06 < jessta_> you can prove non=existance in a limited scope 14:06 < Namegduf> Yes, you can. 14:06 < xyproto> "how syntax can work" is not that limited, though 14:06 < Namegduf> There are proofs, for example, that no natural numbers exist which are neither prime nor the sum of primes. 14:06 < xyproto> Namegduf: yes, but I said "in this connection". Math is something else completely. 14:06 < Namegduf> xyproto: I disagree 14:06 < xyproto> Namegduf: well, I disagree with you too 14:06 < Namegduf> No, you didn't. 14:07 < xyproto> Namegduf: yes I do 14:07 < xyproto> :D 14:07 < Namegduf> Not at that part. 14:07 < xyproto> Namegduf: yes I did 14:07 < xyproto> bbl 14:07 < Namegduf> 14:08 <xyproto> Namegduf: as you probably know, you can't prove non-existance. 14:07 < jessta_> xyproto: the great thing about the current way of doing semiclon insertion is that it allows a REPL 14:07 < Namegduf> "in this connection" was attached to your assertion 14:07 < Namegduf> Which was based on that point 14:07 < Namegduf> Which I think is soundly refuted 14:07 < aiju> it's either day or night 14:08 < aiju> i can proof the nonexistance of any other state 14:08 < Namegduf> At any rate, it's perfectly possible to prove non-existence and the best way to do so is to have it implied by the definition of things. 14:08 < Namegduf> You want behaviour based on syntax for handling of ends of statements. 14:09 < Namegduf> By definition, that requires knowledge of the language syntax (there's a bit of a leap there, but it's acceptable, I hope) 14:09 < Namegduf> By definition, that means either handling it in a place where that knowledge already exists or adding that knowledge to somewhere it doesn't already exist 14:10 < Namegduf> JS's hack does a bizarre combination by going back to statement end insertation after syntax errors occur 14:11 < Namegduf> It's possible that I'm wrong but I think saying that I "can't say" such a thing is off. 14:12 -!- sauerbraten [~sauerbrat@p508CAA66.dip.t-dialin.net] has quit [Remote host closed the connection] 14:14 < waqas> Given some json and a need to get some deep field, can I somehow avoid if a!=nil && a.b!=nil && a.b.c != nil, etc? 14:15 < aiju> write a function for it ;P 14:15 < waqas> I would need to do so in the function ^^ 14:16 < jessta_> you could write a function with a recover() to catch the panic 14:17 < waqas> Sensible, thanks ;) 14:17 < Namegduf> Hmm. 14:17 < Namegduf> Yeah, I should switch to that, really. 14:18 < Namegduf> I have some long JSON extraction and SQL running stuff in one server. 14:18 < waqas> Another option is implementing Unmarshaler for the deep object and json.Unmarshal. But recover() is simpler. 14:19 < aiju> recover() is also evil 14:20 < Namegduf> It's a nice way of handling invalid input, though 14:20 < aiju> you rely on the hardware catching nil pointer references 14:20 < waqas> aiju: http://tvtropes.org/pmwiki/pmwiki.php/Main/GoodIsBoring 14:20 < Namegduf> And? 14:20 < waqas> aiju: I rely on hardware for the good stuff to.. :) 14:20 < waqas> *too 14:21 < Namegduf> I'm pretty sure that such things will cause a panic is either part of the Go spec or considered assumed 14:21 < Namegduf> Given that discussion about making running arbitrary code which can't crash didn't mention it. 14:22 < Namegduf> *about running arbitrary code while guaranteeably not crashing 14:23 < Namegduf> recover() at the top of a request handler is nice, anyway. 14:23 < Namegduf> Even if the user figures out a bug in your code which can crash it, you can recover. 14:23 < Namegduf> (If you get lucky enough that the bug doesn't cause any bad effects to state; arbitrary code exploits would be hard to pull off on Go so not such a problem) 14:25 < Namegduf> I'm not sure I consider leaning on that while parsing input such a bad thing... 14:25 -!- kanru [~kanru@kanru-1-pt.tunnel.tserv15.lax1.ipv6.he.net] has quit [Read error: Operation timed out] 14:28 -!- femtoo [~femto@95-89-249-242-dynip.superkabel.de] has quit [Read error: Connection reset by peer] 14:31 -!- femtoo [~femto@95-89-249-242-dynip.superkabel.de] has joined #go-nuts 14:34 < aiju> a null pointer reference can either (1) return an undefined value (2) crash the system (3) crash the program (4) cause a nice runtime panic 14:35 < aiju> so if you do want to be portable, you should avoid them altogether 14:37 < Namegduf> aiju: Link to that in the specification? 14:37 < Namegduf> C likes to leave a lot undefined 14:37 < Namegduf> Go isn't so fond of that 14:38 < aiju> this is a hardware feature 14:38 < aiju> VAX programmers relied on (1) and this caused LOTS of portability issues 14:38 -!- bugQ [~bug@c-67-171-127-76.hsd1.ut.comcast.net] has joined #go-nuts 14:38 < Namegduf> Invalid array indexing is handled by Go. 14:38 < aiju> nil pointer references are not, afaik 14:39 < Namegduf> I don't think they need to be for any current platform. 14:40 < Namegduf> http://research.swtch.com/2010/02/off-to-races.html <- While nil pointers aren't mentioned, I feel that them not being listed as a problem means at the least I don't need to care about them being one. 14:40 < aiju> there is nothing in the specification about it 14:40 < Namegduf> Is there stuff about array indexing being in bounds? 14:41 < aiju> if the index x is out of range, a run-time panic occurs 14:41 < Namegduf> Okay. 14:41 < Namegduf> At any rate I don't care even if platforms can make it illegal. 14:42 < aiju> In Go, the easiest way to do that is to make the representation a single pointer that points at an immutable structure. 14:42 < aiju> what the fuck 14:42 < aiju> this sounds like "FUCK PERFORMANCE" 14:42 < Namegduf> It is 14:43 < Namegduf> Which is why it doesn't do it 14:43 < Namegduf> Although they reserve judgement on doing it later based on profiling of what it actually does to performance 14:44 < Namegduf> Bear in mind that the data races are considered an implementation bug, so a fix is allowed to depend on implementation details. 14:44 < Namegduf> (In this case, changes to a single word being atomic.) 14:45 -!- ronnyy [~quassel@p4FF1C221.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 14:45 < aiju> can't it use compare&swap to make it atomic? 14:46 < Namegduf> It could on platforms where it wasn't anyway, but it'd have to always use compare and swap for assigning everything pointer-like, and compare and swap is *very* slow 14:47 < aiju> compare and swap is infinitely faster than memory allocation 14:47 < Namegduf> I unno 14:48 < Namegduf> Compare and swap does nasty stuff to cache 14:48 < Namegduf> And hurts multiple cores running in parallel a lot. 14:48 < Namegduf> I don't remember the details but it'd probably be faster to just always run GOMAXPROCS=1 14:48 < aiju> Go does compare&swap all over the place 14:48 < Namegduf> It does it for synchronisation 14:48 < Namegduf> Which is not free 14:48 < Namegduf> Using it everywhere would be equivalent to doing that for every variable assign. 14:49 < bugQ> one thing to note is that go already pushes channels as an alternative to memory sharing 14:50 < aiju> bugQ: yeah 14:50 < Namegduf> aiju: At any rate, they don't need to on real platforms. 14:51 < Namegduf> I *know* x86 and x86_64 have any individual word be updated atomically, and given that blog post I'd be very surprised if ARM was an exception. 14:51 < Namegduf> What else is there? Only other significant one that comes to mind is MIPS 14:51 < aiju> PPC? 14:51 < aiju> PPC is more important than MIPS 14:51 < Namegduf> PPC, yeah. 14:51 < Namegduf> I'd be surprised if any of those had non-atomic word writes, though. 14:52 < Namegduf> They're basically inherently provided by cache lines 14:52 < aiju> i'm never surprised by x86 doing strange things 14:52 < aiju> even less by amd64 14:54 < Namegduf> aiju: I guess I'm just not very sympathic to the way C left huge chunks of things "implementation-defined" for the benefit of 15-bit-word systems no one uses whose compilers were already written and expecting them to rewrite for standards compliance would be too mean 14:55 < Namegduf> So they crapped all over the standard and left people to deal with it for decades 14:55 < aiju> the C standard is total crap 14:55 < aiju> i believe the issue was rather performance 14:56 < Namegduf> Real portability is important, supporting arbitrary "it's allowed to vary even if nothing important does" stuff is silly and irritating to making nice code for everything real. 14:56 < aiju> there ain't no such thing as "real portability", some arch is always going to fuck you up 14:56 < Namegduf> So... I don't care whether technically a Go implementation COULD fail to handle nil pointers and panic or not. I think Go compilers for such arcane platforms should be expected to emit tests before derefs. 14:57 < Namegduf> Slow and ugly, but hey, it's a crappy arch. 14:57 < aiju> "arcane platforms" such as ARM? 14:57 < Namegduf> I would assume that's not the case for ARM platforms supported by Go? 14:57 < aiju> that's the case for MMU-less systems, afaik 14:58 < Namegduf> Care level for my JSON->SQL code running on MMU-less systems: -17/100 14:58 < Namegduf> That does count as an "arcane platform", yes. 14:58 < Namegduf> At least for that kind of code. 14:59 < Namegduf> Can Go run on those, anyway? 14:59 < aiju> well, this seems to be an issue of lazyness vs portability 14:59 < Namegduf> No, it's an issue of maintainability vs portability 15:00 < Namegduf> Making my code significantly uglier to support platforms no one is ever going to want to run it on is a bad idea, laziness or no laziness 15:00 < aiju> "proper checking of input data" vs "just crash if it's odd" 15:00 < Namegduf> "and recover" 15:00 < aiju> (and then hope that Go will recover) 15:00 < Namegduf> Not "hope" 15:01 < bugQ> there is no try 15:01 -!- KingPhilroy [~kingphilr@shc-nat-newhall.stonehill.edu] has joined #go-nuts 15:01 < Namegduf> Portability for significant platforms is worth a fair bit of effort and a fair price in complexity where necessary, but complicating code to support bizarre things like "what if this platform ruins the safety of Go by letting bad code crash without a panic" 15:02 < Namegduf> Is not worth it 15:02 * waqas agrees with Namegduf 15:03 < Namegduf> Definitely not laziness in this case, right now it is the ugly way and I'm going to go back and make it much, much shorter. 15:04 < Namegduf> It's mostly parsing, checking, preparing SQL, checking, executing, checking, scanning results, checking 15:04 < Namegduf> So dropping the checking (or just panicing immediately) would be worth it. 15:04 < aiju> if Go cared about such sequences being short, it would use exceptions intensively 15:05 < Namegduf> No, it would provide a way to shorten them without compromising the ability to rely on random exceptions not being thrown from unknown code. 15:05 < Namegduf> Which gets the best of both worlds. 15:06 < bugQ> also I think it's "panicking" 15:06 < bugQ> >_> 15:07 < Namegduf> Hmm, you're right. 15:07 -!- nettok [~quassel@200.119.160.182] has joined #go-nuts 15:07 < Namegduf> panicking, panics, panicked. 15:07 < Namegduf> Stupid English. 15:07 < bugQ> yeah 15:07 < aiju> english is ridiculously easy and consistent 15:08 < Namegduf> English is like JS 15:08 < aiju> we should use a more arcane and crazy language 15:08 < Namegduf> You read it whichever way doesn't have syntax errors 15:08 < aiju> like ancient greek 15:08 -!- chressie [~chressie@dreggn.in-ulm.de] has quit [Quit: WeeChat 0.3.4] 15:08 < aiju> Namegduf: that's something all natural languages have in common 15:08 < Namegduf> Yes. 15:10 -!- chressie [~chressie@dreggn.in-ulm.de] has joined #go-nuts 15:16 -!- littlebobby [~bob@unaffiliated/littlebobby] has joined #go-nuts 15:17 < nsf> try russian, lol 15:17 < aiju> the "big" package is somehow ugly 15:18 < nsf> aiju: is there anything in the world that you like? :) 15:18 < aiju> blargh 15:18 < aiju> can't you be critical of shit without people asking that retarded question all the time? 15:18 * nsf is in a troll mood 15:18 < aiju> i should wear a t-shirt "YES THERE IS SHIT I LIKE" 15:18 < nsf> :D 15:20 -!- waqas [~waqas@jaim.at] has left #go-nuts [] 15:21 < aiju> http://pastie.org/1718271 15:21 < nsf> ah it uses methods 15:22 < aiju> not as one would expect 15:22 < nsf> one thing I'm sure I don't want to see under any circumstances 15:22 < aiju> a.Mul(b, c) is a = b*c 15:22 < nsf> a math package of any kind that uses methods with names 15:22 < nsf> I think: funcs or operator overloading 15:22 < aiju> well, it makes sense if it was a.Mul(b) 15:22 < nsf> be it BigInt or Vector3 or Matrix4 15:22 < nsf> or whatever 15:22 < aiju> for a *= b 15:22 < nsf> aiju: I don't know 15:22 < nsf> to me methods for math look wrong 15:23 < nsf> because in math there is no such thing as methods 15:23 < nsf> there are functions and operators 15:23 < aiju> well, if you care about performance, such things are important 15:23 < aiju> bignum calculations are usually expensive anyway 15:23 < nsf> you can pass args by a pointer 15:23 < nsf> method is just a syntax for a function 15:23 < aiju> which is the same thing, just ing reen 15:23 < nsf> wrong syntax in that case 15:25 < aiju> interesting 15:25 < aiju> CLISP is only five times slower than Go 15:25 < nsf> oh, btw there is one questionable thing in C 15:25 < nsf> that makes it nice (sort of) for math 15:25 < aiju> nsf: there are many things questionable in C 15:26 < nsf> aiju: no no, I'm making an intro for something I want to talk about 15:26 < nsf> ok 15:26 < nsf> implicit cast 15:26 < nsf> from an array type 15:26 < nsf> to a pointer type 15:26 < nsf> for example: 15:26 < nsf> typedef vec3_t float[3]; 15:26 < nsf> void vec3_add(vec3_t out, vec3_t lhs, vec3_t rhs); 15:26 < nsf> and the usage is nice 15:27 < nsf> vec3_t a = {1,2,3}, b = {1,2,3}, c; 15:27 < nsf> vec3_add(c, a, b); 15:27 < aiju> (it's typedef float vec3_t[3];) 15:27 < nsf> ah, yes 15:27 < nsf> sorry 15:27 < nsf> Go affects me too much :) 15:27 < nsf> anyways 15:28 < huin> as i get used to go, C-like declarations seem more foreign and wrong 15:28 < nsf> the point is, that values are on the stack 15:28 < nsf> and no ugly '&' 15:28 < nsf> for passing pointers to func 15:28 < nsf> do you think it's a nice feature to have? 15:28 < nsf> I mean implicit cast from an array type to a pointer type 15:28 < aiju> i can't really judge 15:29 < nsf> it's very important for me in fact 15:29 < nsf> because I have plans to use my lang for linear math for 3d stuff 15:29 < Namegduf> nsf: To be on the stack would require the same escape analysis as for a pointer 15:29 < aiju> this is a thing i'd really try in practice 15:29 < nsf> Namegduf: we're talking about C at the moment :) 15:29 < nsf> and my lang in that case will be more close to C 15:29 < aiju> and nsf's fornication of Go and C 15:29 < Namegduf> nsf: So your language is not garbage collected? 15:30 < nsf> Namegduf: no 15:30 < Namegduf> Okay then. 15:30 < nsf> because I want 100% compatibility with C, or close to 100% 15:30 < nsf> like importing C headers without any bindings 15:30 < Namegduf> Not an issue then, you don't guarantee that it's safe to stow pointers away anyway. 15:30 -!- bugQ [~bug@c-67-171-127-76.hsd1.ut.comcast.net] has quit [Ping timeout: 248 seconds] 15:30 < nsf> Namegduf: but I will have escape analysis :) 15:30 < aiju> some thing which always bugged me about languages: 15:30 < Namegduf> nsf: Well, you don't need it now. 15:30 < nsf> at least I think it's possible to prove that pointer escapes the stack 15:31 < aiju> almost all arches have flags for carry and overflow and no languages allows me to make use of them 15:31 < nsf> and drop warning 15:31 < aiju> (no language i know, that is) 15:31 < nsf> warnings* 15:31 -!- i___ [~none@69.164.206.224] has quit [Quit: leaving] 15:31 < Namegduf> My favourite overflow handling is probably saturation 15:31 < aiju> nsf: you should add such a thing to your language! 15:31 -!- i__ [~none@unaffiliated/i--/x-3618442] has joined #go-nuts 15:31 < nsf> aiju: what's that? 15:31 < aiju> the carry flag? 15:31 < Namegduf> I'm not sure that's easy to provide, though. 15:32 < nsf> I know there some CPU stuff that isn't available in C 15:32 < huin> aiju: other than ASM, but that's a bad example ;) 15:32 < nsf> aiju: not sure it you're talking about it 15:32 < aiju> for instance 128 bit arithmetic 15:32 < aiju> you either need to do some crazy stuff or resort to ASM 15:33 < aiju> where it is trivial 15:33 < nsf> that carry thing allows you to handle overflows right? 15:33 < aiju> overflow and carry are two things 15:33 < aiju> basically overflow is the signed thing and carry the unsigned thing 15:33 < aiju> 32767 + 1 = -32768 -> overflow 15:33 < aiju> 65535 + 1 = 0 -> carry 15:33 < nsf> I see 15:33 < aiju> (obviously 16-bit arithmetic) 15:34 < exch> interesting https://bugzilla.redhat.com/show_bug.cgi?id=638477#c129 15:34 < aiju> you can just carry over the carry to the next word and perform 32-bit arithmetic thus 15:34 < nsf> I know that pypy makes use of that actually 15:34 < nsf> their JIT or something 15:34 < exch> this seems to have a fairly rigid split in the dev community 15:34 < aiju> some cute way to handle such things is idioms 15:34 < aiju> like the rotation instructions 15:34 -!- shvntr [~shvntr@119.121.55.178] has quit [Ping timeout: 260 seconds] 15:34 < nsf> aiju: interesting, but since my first target of compilation is C anyway 15:35 < nsf> I think it will be postponed :) 15:35 < huin> bit rotation (similar to bit shift)? 15:35 < aiju> huin: yeah 15:35 < aiju> (x << 8) | (x >> 8) will be compiled to a rotate instruction 15:35 < aiju> (or a byte swap instruction, in that case) 15:35 < nsf> interesting 15:35 < nsf> how about a rotation operator? :) 15:36 < aiju> it's unnecessary 15:36 < huin> how often do you honestly need it, though? 15:36 < nsf> hehe 15:36 < aiju> huin: yeah, that's kinda the point 15:36 < aiju> instead that idiom replaces it conveniently 15:36 < huin> maybe in crypto... 15:36 < huin> pretty niche, in any case 15:36 < aiju> instead of adding another feature, you add an idiom 15:36 < aiju> huin: i'm just giving an example 15:37 < huin> on the carry/overflow - i've sometimes wanted that 15:37 -!- shvntr [~shvntr@110.210.40.249] has joined #go-nuts 15:37 < nsf> I didn't but hey if it's in CPU, then there is a place for that in a low level langauge 15:38 < nsf> somewhere :) 15:39 < aiju> one shouldn't overdo that idiom thing, though 15:40 < aiju> or one ends up with crap like Verilog 15:40 < nsf> I won't do anything because I don't even know how can I use this feature :) 15:40 < aiju> where almost every hardware feature has to be "emulated" just to get the compiler recoginizing you're trying to do that 15:41 < aiju> instead of adding some sort of RAM statement or something, you just place thousands of flip flops and hope the compiler recognizes you mean to use RAM 15:41 -!- shvntr [~shvntr@110.210.40.249] has quit [Client Quit] 15:41 < nsf> but I'm open to contributions and I don't accept ideas without contributions unless I'm willing to implement them myself :) 15:41 < nsf> at the moment though, everything is totally closed 15:42 < nsf> hehe 15:45 < aiju> exch: that thing is crazy 15:45 < aiju> so glibc broke memcpy for no reason 15:45 < aiju> made it slower 15:45 < aiju> made it bigger and more complicated 15:45 < aiju> just WHAT THE FUCK 15:46 < nsf> :) 15:46 < aiju> Pike is spinning in his bed 15:46 < aiju> there is no memcpy in Plan 9 ;P 15:46 -!- wrtp [~rog@92.17.50.183] has quit [Quit: wrtp] 15:46 < exch> I actually disagree with torvalds there. While user experience is important, specs exist for a reason. Randomly breaking a spec serves nobiody any good and expecting downstream apps to 'just supply a workaround and stop whining' is bad form all around 15:46 < aiju> oh wait, there is, it's just aliased to memmove 15:47 < aiju> exch: what the fuck? memcpy is just stupid 15:47 < aiju> it made sense on the PDP-11 (perhaps) 15:47 < aiju> it's entirely ridiculous on modern machines 15:47 < aiju> (memcpy as the weird ass memcpy which shits its pants on overlapping areas) 15:48 < exch> then the spec needs to be revised. Don't just go in and change shit when yuo know it's going to break everything downstream 15:48 < nsf> what have they done with memcpy? 15:48 < nsf> I remember something about it 15:48 < nsf> but not sure what it was 15:48 < aiju> nsf: they added "special cases" to make it "faster" (read: slower) 15:48 < nsf> like? 15:48 < aiju> and it broke compatibility with e.g. Flash player 15:48 < aiju> i have no clue ;P 15:49 < nsf> afaik it wasn't exactly conforming to spec 15:49 < nsf> and some software was relying on that 15:49 < nsf> and then they've fixed it 15:49 < nsf> e.g. it was handling overlapped memory correctly 15:49 < nsf> and now it doesn't 15:49 < nsf> something like that 15:49 < aiju> software relies on memcpy shitting its pants? 15:49 < nsf> I'm not sure but that's what I remember 15:50 < nsf> well I partially agree with linus and partially disagree 15:50 < nsf> the real problem in this issue is a shared library 15:51 < nsf> fuck shared libraries :) 15:51 < exch> that to 15:51 < aiju> haha ooh right 15:51 < aiju> https://bugzilla.redhat.com/show_bug.cgi?id=638477#c38 15:51 < aiju> what the fuck 15:51 < aiju> this is a really gay coding style 15:52 < nsf> linus just shows he's cool because he can easily do inline assembly in C 15:52 < nsf> I can't 15:52 < nsf> :( 15:53 < aiju> inline assembly is pure evil 15:53 < aiju> there is no reason ever to do it 15:53 < aiju> esp. in such cases 15:53 < aiju> it's just a C function header wrapped around assembly code, GOSH JUST WRITE FUCKING ASSEMBLY 15:53 < nsf> ah, see comment 40 15:54 < nsf> it's that issue about overlapping indeed 15:54 < nsf> so, I don't think glibc guys did something really bad 15:54 < nsf> but unportable software got fucked up 15:54 < nsf> because they weren't following standards 15:55 < nsf> and I agree with exch they do exist for a reason 15:55 < aiju> glibc guys do evil all the time 15:55 < aiju> standards exist for the reason of being ignored 15:55 < nsf> and frankly I use archlinux I didn't notice that issue 15:55 < nsf> fuck redhat :) 15:56 < nsf> buggy software should be fixed that's what testing communities for 15:56 < nsf> and if they've shipped that bug in a major distro release or something 15:56 < nsf> that's just stupid :) 15:59 < exch> This touches on a much wider issue though. For me anyways. I've always had a pretty hardline stance on matters concerning spec-adherance. The first time I ran into this was with some web stuff many years ago. The fact that browsers implement 'quirks mode' rendering to deal with malformed HTML just pissed me off to no end 15:59 < Namegduf> Using memcpy overlapping when the docs never said whether it worked or didn't work might be worth worrying about. 15:59 < Namegduf> For backwards compatibility. 15:59 < exch> If I were to write a browser, any malformed content would just yield big "YOU SUCK" page/ 15:59 < Namegduf> Supporting overlapping when it very explicitly says THIS DOES NOT WORK WITH OVERLAPPING COPIES 16:00 < Namegduf> And has always done so... 16:00 < huin> exch: unfortunately that only hurts the user, if the dev didn't test on that browser 16:00 < huin> exch: although i agree, in principle 16:00 < huin> exch: no doubt it'd get nasty on complex websites with dynamic content 16:01 < exch> huin: Yes, that brings about another problem: every browser having their own idea of what 'proper rendering' means 16:01 < nsf> guys, but common it's a such an easy thing to fix 16:01 < nsf> just replace all memcpy stuff to xmemcpy 16:01 < nsf> which calls memmove 16:01 < nsf> :) 16:01 < huin> exch: yup. and the easy option was taken, with good and bad effects :( 16:01 < huin> compromise - nobody is happy :) 16:01 < Namegduf> Not really 16:01 < Namegduf> There's a standard for proper stuff 16:02 < Namegduf> It's just some browser chose to not even try to be proper 16:02 < aiju> nsf: what the fuck is xmemcpy? 16:02 < aiju> use memmove 16:02 < nsf> function that calls memmove 16:02 < aiju> and alias memcpy to memmove 16:02 < Namegduf> Because it helped them boost their market share by breaking other people 16:02 < aiju> problem solved 16:02 < nsf> well you can do that as well 16:03 < huin> #define IREADTHEMEMCPYMANPAGE ? 16:04 < nsf> also I thought that memcpy is changed to something like __builtin_memcpy by most compilers anyway 16:04 < nsf> which converts it to asm or something 16:04 < aiju> not afaik 16:05 < aiju> oh wait, gcc does 16:06 < aiju> only if the size is known 16:06 < nsf> so, I totally doesn't understand how they've stumbled on that bug 16:06 < nsf> ah 16:06 < nsf> I see 16:06 < aiju> 8c does nothing of those obscenities ;P 16:07 < aiju> or they use -O0 16:15 < Fish-> do you know if you can disable builtin functions from gcc? 16:18 -!- femtoo [~femto@95-89-249-242-dynip.superkabel.de] has quit [Ping timeout: 250 seconds] 16:23 -!- itrekkie [~itrekkie@ip72-201-208-165.ph.ph.cox.net] has joined #go-nuts 16:25 -!- femtoo [~femto@95-89-249-242-dynip.superkabel.de] has joined #go-nuts 16:26 < nsf> Fish-: I think it's possible somehow, yeah 16:27 < Fish-> how? 16:27 < aiju> -fno-builtin 16:27 < nsf> I don't know :) 16:28 < aiju> disables them entirely 16:28 < nsf> http://www.delorie.com/gnu/docs/gcc/gcc_81.html 16:28 < nsf> indeed 16:28 < Fish-> aiju: it doesn't work properly with -static 16:28 < aiju> uh huh 16:28 < steven> <3 16:28 < aiju> gcc / glibc are just broken 16:29 < Fish-> the only way I found is using another libc than glibc 16:29 < nsf> there is a nice one I think 16:29 < nsf> one sec 16:29 < nsf> can't remember the name 16:29 < aiju> uclibc? 16:29 < aiju> bionic? 16:29 < aiju> tinylibc? 16:29 < nsf> aiju: that's why I can't remember the name 16:29 < aiju> haha 16:29 < nsf> it doesn't have libc in it 16:29 < nsf> and it's not bionic 16:31 < nsf> http://www.etalabs.net/musl/ 16:31 < nsf> that one 16:31 < nsf> it's fucking hard to find it 16:32 < nsf> of course it doesn't provide as much as glibc 16:32 < nsf> but it's nice I think 16:32 < nsf> never tried it though 16:33 < aiju> many of those seem nice but actually aren't ;P 16:33 < nsf> the ugly part is LGPL license 16:33 < nsf> so, even if it's small you can't really link it statically 16:33 < nsf> aiju: I've seen the code 16:33 < nsf> it has no shit loads of macros 16:33 < nsf> at least 16:34 < aiju> "Symbol versioning" should be "no" in green 16:34 < nsf> :D 16:34 < Namegduf> XD 16:35 < aiju> and license LGPL should be blood red 16:35 < aiju> 16 KB of dynamic overhead for hello world 16:35 < Namegduf> Yeah, those assholes, not giving away their work unconditionally 16:35 < Namegduf> :P 16:35 < aiju> Namegduf: you may be sarcastic, but that's exactly my point 16:35 < nsf> I'm fine with LGPL 16:35 < nsf> but if your library is so small 16:36 < Namegduf> That's true 16:36 < nsf> that it makes sense to link it statically 16:36 < nsf> wtf 16:36 < aiju> LGPL is pure evil because it favours dynamic linking 16:36 < nsf> yeah 16:36 < nsf> sort of 16:36 < Namegduf> Can't you link it statically and distribute just the unchanged source of the library or somethign? 16:36 < aiju> static linked Hello World was 1 KB on V6 :\ 16:36 < Namegduf> Or am I completely nuts? 16:36 < nsf> Namegduf: you need to distribute object files 16:36 < nsf> so that RMS could relink it with modified version 16:37 < nsf> :) 16:37 < Namegduf> Ah. 16:39 -!- itrekkie [~itrekkie@ip72-201-208-165.ph.ph.cox.net] has quit [Quit: itrekkie] 16:40 -!- ronnyy [~quassel@p4FF1C221.dip0.t-ipconnect.de] has joined #go-nuts 16:48 -!- stalled [~stalled@unaffiliated/stalled] has quit [Ping timeout: 252 seconds] 16:57 -!- tobier [~tobier@c-1e9de055.712-1-64736c11.cust.bredbandsbolaget.se] has quit [Read error: Operation timed out] 16:57 -!- tobier [~tobier@c-1e9de055.712-1-64736c11.cust.bredbandsbolaget.se] has joined #go-nuts 17:00 -!- waqas [~waqas@jaim.at] has joined #go-nuts 17:01 -!- stalled [~stalled@unaffiliated/stalled] has joined #go-nuts 17:10 -!- rutkowski [~adrian@178235051224.walbrzych.vectranet.pl] has joined #go-nuts 17:10 -!- Venom_X [~pjacobs@74.61.90.217] has joined #go-nuts 17:11 -!- Venom_X [~pjacobs@74.61.90.217] has quit [Client Quit] 17:14 < exch> http://gcc.gnu.org/gcc-4.6/ wasn't this in already? 17:14 < exch> Go support that is 17:14 < nsf> exch: what exactly? 17:15 < exch> it makes a note that Go support was added to GCC 17:15 < nsf> yeah 17:15 < nsf> it was in a gccgo branch for a while 17:15 < nsf> it was merged in between 4.5 and 4.6 17:16 < exch> ah 17:17 < Namegduf> "It may or may not work on other platforms" 17:17 < Namegduf> The may is interesting 17:17 < nsf> I think it means it wasn't tested :) 17:17 < Namegduf> I wonder how that gccgo handles goroutines. 17:18 < Namegduf> Since it supports discontiguous stacks now, it could at least use cheaper threads. 17:18 < exch> I've never used gccgo.. didnt gccgo used to have 1 goroutine per thread? 17:18 < taruti> yes 17:18 < Namegduf> Yeah, and I've not heard it changed. 17:19 < Namegduf> It has GC now but goroutines are still very expensive 17:20 < Namegduf> gccgo is really a better thing for distributors than 6g and co 17:20 < Namegduf> gcc is already figured out for them. 17:20 < nsf> Namegduf: there are few major problems 17:20 < nsf> cgo won't work with gccgo? 17:20 < Namegduf> I thought gccgo didn't need it. 17:20 < nsf> yeah but you see 17:20 < Namegduf> (Right now) 17:21 < nsf> bindings authors 17:21 < nsf> use it 17:21 < Namegduf> Yeah, that's a problem. 17:21 < nsf> all bindings are incompatible with gccgo :) 17:21 < Namegduf> Build systems, too. 17:21 < nsf> and when there will be a next major language change 17:21 < nsf> another problem 17:21 < Namegduf> Yeah, those are going to be a problem until they quieten down 17:21 < nsf> people will have to use gcc-svn 17:21 < nsf> yeah 17:21 < Namegduf> The build system stuff is a bigger issue, IMO 17:22 < Namegduf> gccgo and 6g are not interchangeable and if you use 6g you have code and build system changes to make. 17:22 < nsf> yeah 17:22 < Namegduf> Er, if you use cgo 17:27 -!- bugQ [~bug@c-67-171-127-76.hsd1.ut.comcast.net] has joined #go-nuts 17:29 -!- |Craig| [~|Craig|@panda3d/entropy] has joined #go-nuts 17:30 -!- viirya [~viirya@cml506-25.csie.ntu.edu.tw] has quit [Ping timeout: 260 seconds] 17:31 -!- viirya [~viirya@cml506-25.csie.ntu.edu.tw] has joined #go-nuts 17:34 -!- nsf [~nsf@jiss.convex.ru] has quit [Quit: WeeChat 0.3.4] 17:53 -!- TheSeeker [~n@99-153-250-110.lightspeed.irvnca.sbcglobal.net] has quit [Ping timeout: 250 seconds] 17:54 -!- fhs [~fhs@pool-74-101-66-112.nycmny.east.verizon.net] has joined #go-nuts 17:57 -!- Fish- [~Fish@bus77-2-82-244-150-190.fbx.proxad.net] has quit [Quit: So Long, and Thanks for All the Fish] 17:57 -!- Fish- [~Fish@bus77-2-82-244-150-190.fbx.proxad.net] has joined #go-nuts 17:58 -!- TheSeeker [~n@99-153-250-110.lightspeed.irvnca.sbcglobal.net] has joined #go-nuts 18:04 -!- dRbiG [drbig@unhallowed.pl] has quit [Ping timeout: 250 seconds] 18:05 -!- dRbiG [drbig@unhallowed.pl] has joined #go-nuts 18:05 -!- zimsim [~simon@87.72.77.195] has quit [Ping timeout: 252 seconds] 18:08 -!- wrtp [~rog@92.17.50.183] has joined #go-nuts 18:08 -!- thomas_b [~thomasb@cm-84.215.47.51.getinternet.no] has quit [Quit: leaving] 18:10 -!- ronnyy [~quassel@p4FF1C221.dip0.t-ipconnect.de] has quit [Read error: Operation timed out] 18:10 -!- ronnyy [~quassel@p4FF1C221.dip0.t-ipconnect.de] has joined #go-nuts 18:12 -!- tensorpudding [~user@99.148.205.193] has joined #go-nuts 18:21 -!- zimsim [~simon@87.72.77.195] has joined #go-nuts 18:22 -!- foocraft [~dsc@78.101.64.62] has joined #go-nuts 18:22 -!- napsy [~luka@tm.213.143.73.175.lc.telemach.net] has joined #go-nuts 18:23 -!- thomas_b [~thomasb@cm-84.215.47.51.getinternet.no] has joined #go-nuts 18:26 < plexdev> http://is.gd/H4Viar by [Ian Lance Taylor] in go/test/ -- test: match gccgo error messages for init.go 18:26 < plexdev> http://is.gd/jD9lcP by [Rob Pike] in 12 subdirs of go/src/pkg/ -- testing: shorten some more tests 18:44 -!- [Pete_27] [~noname@110-174-103-31.static.tpgi.com.au] has quit [Ping timeout: 240 seconds] 18:52 -!- zimsim [~simon@87.72.77.195] has quit [Ping timeout: 276 seconds] 18:54 -!- XenoPhoenix [~Xeno@cpc13-aztw24-2-0-cust23.aztw.cable.virginmedia.com] has quit [Quit: "Wait... what?!"] 18:56 -!- ronnyy [~quassel@p4FF1C221.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 19:00 -!- virtualsue [~chatzilla@nat/cisco/x-annijnwpdogwwxvy] has quit [Ping timeout: 276 seconds] 19:02 -!- Project_2501 [~Marvin@82.84.93.120] has joined #go-nuts 19:04 -!- st-2451 [~st-2451@a89-154-147-132.cpe.netcabo.pt] has quit [Read error: Connection reset by peer] 19:06 -!- zimsim [~simon@87.72.77.195] has joined #go-nuts 19:08 -!- st-7097 [~st-7097@a89-154-147-132.cpe.netcabo.pt] has joined #go-nuts 19:12 -!- dju [dju@fsf/member/dju] has joined #go-nuts 19:12 -!- dju [dju@fsf/member/dju] has quit [Read error: Connection reset by peer] 19:14 -!- Project_2501 [~Marvin@82.84.93.120] has quit [Read error: Connection reset by peer] 19:15 -!- st-7097 [~st-7097@a89-154-147-132.cpe.netcabo.pt] has quit [Read error: Connection reset by peer] 19:15 -!- Project_2501 [~Marvin@82.84.93.120] has joined #go-nuts 19:20 -!- st-7523 [~st-7523@a89-154-147-132.cpe.netcabo.pt] has joined #go-nuts 19:37 -!- st-7523 [~st-7523@a89-154-147-132.cpe.netcabo.pt] has quit [Remote host closed the connection] 19:41 -!- st-7869 [~st-7869@a89-154-147-132.cpe.netcabo.pt] has joined #go-nuts 19:43 -!- st-7869 [~st-7869@a89-154-147-132.cpe.netcabo.pt] has quit [Remote host closed the connection] 19:43 -!- jokoon [~zonax@feu30-1-82-242-58-229.fbx.proxad.net] has joined #go-nuts 19:47 < steven> crap 19:47 < steven> is go's zlib broken? 19:48 < steven> using the same compression level, im getting 2 different outputs when compressing the same content, one in ruby and one in Go 19:48 < steven> the ruby one matches up with C's zlib (since thats what it uses internally). the Go one doesnt 19:49 < taruti> that is allowed 19:49 < steven> oh. just as long as it deflates to the same thing? 19:50 < ww> android is so fscking backwards 19:50 < aiju> well, it's android 19:50 < skelterjohn> they can't all be ios 19:50 < steven> ios is pretty sweet 19:50 < steven> objc is my first real love <3 19:50 < aiju> the existence of something worse doesn't make anything better 19:50 < ww> so i gave up on using the c libraries and am just talking its json protocol over the socket to SL4A -the scripting env used by python and ruby and stuff 19:50 < aiju> and i prefer OSes with multitasking, even on cellphones ;P 19:50 < steven> all about perspective though 19:50 < skelterjohn> goodness is sort of relative, aiju 19:50 < skelterjohn> so, i disagree 19:51 < ww> it works just fine as far as it goes. 19:51 < ww> now you'd think my go program could start the proxy if it doesn't exist on a particular port 19:51 < ww> well no, you're supposed to use their thing to start your program 19:52 < ww> so i can start the proxy, but there's no way other than looking at the phone's screen to find out what port it is running on 19:52 -!- st-7943 [~st-7943@a89-154-147-132.cpe.netcabo.pt] has joined #go-nuts 19:54 -!- tav [~tav@92.7.141.101] has quit [Quit: tav] 19:54 -!- st-7943 [~st-7943@a89-154-147-132.cpe.netcabo.pt] has quit [Remote host closed the connection] 19:54 -!- TheMue [~TheMue@p5DDF564C.dip.t-dialin.net] has joined #go-nuts 19:57 -!- virtualsue [~chatzilla@nat/cisco/x-twlhopsmnoryzyhc] has joined #go-nuts 19:58 < dforsyth> finally got go-sdl to build without modification 19:58 < dforsyth> the solution: a fast retreat back to freebsd 19:58 -!- kronoz [~user@customer4523.pool1.Croydon-GLN2000-BAS0001.orangehomedsl.co.uk] has joined #go-nuts 19:58 -!- st-8196 [~st-8196@a89-154-147-132.cpe.netcabo.pt] has joined #go-nuts 19:59 < lorenzo> does anybody from the core team hang out here? 19:59 < aiju> unlikely 19:59 < skelterjohn> iant does 19:59 < aiju> iant is core team? 20:00 < skelterjohn> he is a google employee who works on go full time 20:00 < skelterjohn> also adg 20:00 < lorenzo> ah - Andrew Gerran[dt]? 20:00 < lorenzo> cool. 20:00 < skelterjohn> yes 20:00 < lorenzo> (sorry for sp Andrew) 20:00 < lorenzo> I would say a google employee working on go full time is pretty core :) 20:00 < skelterjohn> he'll just call you larry, so it evens out 20:01 < lorenzo> haha 20:01 < lorenzo> fair enough 20:02 -!- pothos_ [~pothos@111-240-167-52.dynamic.hinet.net] has joined #go-nuts 20:04 -!- pothos [~pothos@111-240-170-131.dynamic.hinet.net] has quit [Ping timeout: 248 seconds] 20:09 -!- Project-2501 [~Marvin@82.84.87.96] has joined #go-nuts 20:09 < huin> hm 20:11 -!- Project_2501 [~Marvin@82.84.93.120] has quit [Ping timeout: 246 seconds] 20:17 < langenzo> naming is hard. 20:19 < bugQ> heh 20:20 -!- rutkowski [~adrian@178235051224.walbrzych.vectranet.pl] has quit [Quit: WeeChat 0.3.3-dev] 20:21 < ljs> better. now I will make no further mention of it. :) 20:36 -!- zonax9 [~zonax@feu30-1-82-242-58-229.fbx.proxad.net] has joined #go-nuts 20:40 -!- jokoon [~zonax@feu30-1-82-242-58-229.fbx.proxad.net] has quit [Ping timeout: 260 seconds] 20:48 -!- edsrzf [~chickench@122-61-221-144.jetstream.xtra.co.nz] has joined #go-nuts 20:54 -!- ExtraSpice [XtraSpice@88.118.35.153] has quit [Read error: Connection reset by peer] 20:56 -!- Project_2501 [~Marvin@82.84.95.168] has joined #go-nuts 20:58 -!- littlebobby [~bob@unaffiliated/littlebobby] has quit [Ping timeout: 240 seconds] 20:59 -!- Project-2501 [~Marvin@82.84.87.96] has quit [Ping timeout: 250 seconds] 21:00 -!- stalled [~stalled@unaffiliated/stalled] has quit [Read error: Connection reset by peer] 21:01 -!- femtooo [~femto@95-89-249-242-dynip.superkabel.de] has joined #go-nuts 21:04 -!- femtoo [~femto@95-89-249-242-dynip.superkabel.de] has quit [Ping timeout: 250 seconds] 21:06 -!- littlebobby [~bob@85.239.101.124] has joined #go-nuts 21:06 -!- littlebobby [~bob@85.239.101.124] has quit [Changing host] 21:06 -!- littlebobby [~bob@unaffiliated/littlebobby] has joined #go-nuts 21:11 -!- stalled [~stalled@unaffiliated/stalled] has joined #go-nuts 21:16 -!- rlab_ [~Miranda@91.200.158.34] has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org] 21:17 -!- nsf [~nsf@jiss.convex.ru] has joined #go-nuts 21:19 < ww> https://bitbucket.org/ww/godroid 21:19 < ww> *sigh* 21:24 -!- nettok_ [~quassel@200.119.167.36] has joined #go-nuts 21:25 -!- nettok [~quassel@200.119.160.182] has quit [Ping timeout: 252 seconds] 21:31 -!- Fish- [~Fish@bus77-2-82-244-150-190.fbx.proxad.net] has quit [Quit: So Long, and Thanks for All the Fish] 21:37 -!- bugQ [~bug@c-67-171-127-76.hsd1.ut.comcast.net] has quit [Ping timeout: 240 seconds] 21:44 -!- nsf [~nsf@jiss.convex.ru] has quit [Quit: WeeChat 0.3.4] 21:45 -!- bugQ [~bug@c-67-171-127-76.hsd1.ut.comcast.net] has joined #go-nuts 21:45 -!- Natch [~natch@c-6dcde155.25-4-64736c10.cust.bredbandsbolaget.se] has joined #go-nuts 21:46 -!- Natch| [~natch@c-6dcde155.25-4-64736c10.cust.bredbandsbolaget.se] has quit [Read error: Operation timed out] 21:51 -!- st-8196 [~st-8196@a89-154-147-132.cpe.netcabo.pt] has quit [Read error: Connection reset by peer] 21:52 -!- waqas [~waqas@jaim.at] has left #go-nuts [] 21:57 -!- sav [~lsd@peirce.xored.org] has quit [Remote host closed the connection] 21:57 < bortzmeyer> ww: hmmm, better to wait for something less... empty before announcing it? 21:57 -!- ildorn [~ildorn@dslb-188-099-197-208.pools.arcor-ip.net] has joined #go-nuts 22:01 -!- bortzmeyer [~stephane@2a01:e35:8bd9:8bb0:ecb8:91b8:365d:1c0e] has quit [Quit: Leaving.] 22:05 -!- ildorn [~ildorn@dslb-188-099-197-208.pools.arcor-ip.net] has quit [Quit: Leaving.] 22:09 < steven> oh sweet 22:09 < steven> even though Go's zlib compression/decompression is different than C's zlib, they're interchangably compatible. 22:09 < steven> which means i can ignore the fact that one is different than the other :) 22:10 < aiju> what are you talking about? 22:10 < steven> deflating (compressing) the same data using Go and using C, gives different output 22:10 < steven> i was worried about that, and thought "oh crap. this means i cant use Go with data that was compressed with C's zlib" 22:10 < aiju> sounds bad 22:11 < str1ngs> not everyone uses C 22:11 < steven> but nope, i tested it, its fine. they can read each other's compressed data just fine 22:11 < str1ngs> C's zlib.. 22:11 < steven> so, we're good :) 22:11 < str1ngs> of course 22:11 < steven> i almost fully reverse-engineered git's 4 different object-file formats 22:11 < steven> blob is the easiest, tree is pretty easy, and commit is too. i havent done tag yet 22:11 < Namegduf> Yeah 22:12 -!- m4dh4tt3r [~Adium@c-69-181-223-245.hsd1.ca.comcast.net] has joined #go-nuts 22:12 < Namegduf> Different deflate implementations or even aggressiveness can output different stuff 22:12 < steven> but they all inflate it just fine regardless, it seems. 22:13 < str1ngs> there more, transports ie ssh/http/tls working with the index. refs etc etc 22:13 < Namegduf> It's like a kind of odd language for representing arbitrary data, inflating is reading and doing what it says. 22:13 < Namegduf> I think Russ Cox had a zip file that decompressed to itself up. 22:13 < Namegduf> I like the idea of one which decompresses to a slightly bigger version of itself, myself. 22:13 -!- pingveno [~pingveno@c-98-246-133-8.hsd1.or.comcast.net] has quit [Ping timeout: 252 seconds] 22:14 * TheMue checked a new version of his Redis client in 22:15 -!- pingveno [~pingveno@c-98-246-133-8.hsd1.or.comcast.net] has joined #go-nuts 22:16 < steven> whats redis anyway? 22:16 < steven> you seem pretty psyched about yourclient 22:17 < TheMue> steven: A nosql database, pretty fast. Got about 8500 ops/sec (mostly inserts) here 22:18 < TheMue> steven: Just doing some advertisement to not let the stuff rotten in a repo like tons of good other code too 22:24 -!- st-8942 [~st-8942@a89-154-147-132.cpe.netcabo.pt] has joined #go-nuts 22:31 -!- TheMue [~TheMue@p5DDF564C.dip.t-dialin.net] has quit [Quit: TheMue] 22:34 -!- huin [~huin@91.85.185.181] has quit [Quit: leaving] 22:35 -!- littlebobby [~bob@unaffiliated/littlebobby] has quit [Quit: Ex-Chat] 22:36 -!- st-8942 [~st-8942@a89-154-147-132.cpe.netcabo.pt] has quit [Read error: Connection reset by peer] 22:41 -!- foocraft [~dsc@78.101.64.62] has quit [Ping timeout: 276 seconds] 22:44 -!- foocraft [~dsc@78.101.95.201] has joined #go-nuts 22:47 < str1ngs> ww: any luck? 22:50 < ww> yes, via the brain damaged SL4A api proxy 22:50 < ww> so just use 5g and talk to the json thing... 22:51 < ww> problem is, no way of telling what port the json thing runs on without looking at the phone's screen or writing stuff in java 22:51 < str1ngs> ww: ah I messed around abit and noticed that cgo gets cross compiled to target arch. which mean should work with a native complier 22:51 < ww> str1ngs: quite likely 22:51 -!- bugQ [~bug@c-67-171-127-76.hsd1.ut.comcast.net] has quit [Remote host closed the connection] 22:52 < ww> though the SL4A site suggests that this is not a good strategy: "c libraries are for making java things faster not for writing c apps" 22:52 < aiju> hahaha 22:52 < aiju> libraries are for pissing off people's depending on libraries not for writing apps ;P 22:52 < str1ngs> ww: sl4a is a bridge? 22:53 < ww> yes 22:53 < ww> it is what the python and ruby and suchlike use 22:53 < str1ngs> ah 22:53 -!- bugQ [~bug@c-67-171-127-76.hsd1.ut.comcast.net] has joined #go-nuts 22:53 < ww> but it's a slightly brain damaged bridge that wants to "manage" your "script" 22:54 -!- Tuller [~tuller@c-68-33-63-208.hsd1.va.comcast.net] has joined #go-nuts 22:54 < ww> so i have the go app that tries to connect and then starts the bridge if it can't. but you can't tell the bridge what port to listen on and can't find out 22:56 -!- femtooo [~femto@95-89-249-242-dynip.superkabel.de] has quit [Read error: Connection reset by peer] 22:56 < ww> one day someone will write jg that compiles to java and then we'll all be sorry 22:57 < aiju> s/be sorry/get out our shotguns/ 22:57 < str1ngs> I thought that would be the best way. 23:10 -!- nettok_ [~quassel@200.119.167.36] has quit [Ping timeout: 276 seconds] 23:11 -!- Project-2501 [~Marvin@dynamic-adsl-94-36-151-145.clienti.tiscali.it] has joined #go-nuts 23:12 -!- virtualsue [~chatzilla@nat/cisco/x-twlhopsmnoryzyhc] has quit [Ping timeout: 240 seconds] 23:14 -!- Project_2501 [~Marvin@82.84.95.168] has quit [Ping timeout: 248 seconds] 23:22 -!- Tuller [~tuller@c-68-33-63-208.hsd1.va.comcast.net] has quit [Quit: Computer has gone to sleep.] 23:23 -!- photron [~photron@port-92-201-123-16.dynamic.qsc.de] has quit [Ping timeout: 250 seconds] 23:27 < mpl> I've just updated to release. now how do I get/build the gofix tool? 23:29 < exch> it should be there already. Likely only in the weekly build though 23:34 < mpl> hmm weird, I've just rebuit, and fixed the os.StartProcess, and I get that: undefined: os.StartProcess 23:34 < mpl> same for os.ProcAttr 23:35 -!- crawshaw [~crawshaw@216.239.45.130] has joined #go-nuts 23:37 < mpl> oh ffs 23:37 < mpl> forgot to hg pull first. 23:39 -!- Tuller [~tuller@c-68-33-63-208.hsd1.va.comcast.net] has joined #go-nuts 23:40 < str1ngs> for os.Open if I'm only reading I assume permission mask 0000 is ok? 23:41 -!- Tuller [~tuller@c-68-33-63-208.hsd1.va.comcast.net] has quit [Client Quit] 23:45 -!- tav [~tav@92.7.141.101] has joined #go-nuts 23:51 -!- bugQ [~bug@c-67-171-127-76.hsd1.ut.comcast.net] has quit [Ping timeout: 240 seconds] 23:52 -!- jokoon [~zonax@feu30-1-82-242-58-229.fbx.proxad.net] has quit [Quit: Leaving] 23:55 < mpl> hmm, still the same. updated to release and yet os/exec.go still has the old version of StartProcess 23:58 -!- bugQ [~bug@c-67-171-127-76.hsd1.ut.comcast.net] has joined #go-nuts --- Log closed Sun Mar 27 00:00:50 2011