--- 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