code logs -> 2011 -> Mon, 18 Apr 2011< code.20110417.log - code.20110419.log >
--- Log opened Mon Apr 18 00:00:10 2011
01:27 Derakon [Derakon@8E7DA3.11EB2E.8356BF.B82ACB] has quit [[NS] Quit: And poof! I am gone.]
02:11
< ToxicFrog>
"This person wound up confusing branching with commits somehow and at the end of the day we had a source code control shrub."
02:14
< Alek>
ahaha
02:34 gnolam [lenin@Nightstar-38637aa0.priv.bahnhof.se] has quit [[NS] Quit: Z?]
02:39 Stalker [Z@3A600C.A966FF.5BF32D.8E7ABA] has quit [Ping timeout: 121 seconds]
03:03 Finerty is now known as Vornicus
04:06 SmithKurosaki [smith@Nightstar-1e66ccde.dsl.teksavvy.com] has quit [Ping timeout: 121 seconds]
05:28 ToxicFrog [ToxicFrog@ServerAdministrator.Nightstar.Net] has quit [Operation timed out]
05:40 Kindamoody[zZz] is now known as Kindamoody
05:55 kwsn is now known as kwsn\t-2
05:57 kwsn\t-2 [kwsn@BAD19E.B5A83A.180240.E5184B] has quit [[NS] Quit: moo]
06:12 SmithKurosaki [smith@Nightstar-1e66ccde.dsl.teksavvy.com] has joined #code
06:57 AnnoDomini [annodomini@D553D1.9D4909.B9D09F.0C9BA3] has joined #code
07:07 ToxicFrog [ToxicFrog@ServerAdministrator.Nightstar.Net] has joined #code
07:14 Kindamoody is now known as Kindamoody|out
07:44 celticminstrel [celticminstre@Nightstar-f8b608eb.cable.rogers.com] has quit [[NS] Quit: And lo! The computer falls into a deep sleep, to awake again some other day!]
08:09 Vornicus is now known as Vornicus-Latens
09:16 Stalker [Z@3A600C.A966FF.5BF32D.8E7ABA] has joined #code
11:20 Attilla [Some.Dude@Nightstar-92c9199f.cable.virginmedia.com] has joined #code
11:30 Kindamoody|out is now known as Kindamoody
12:03 gnolam [lenin@Nightstar-38637aa0.priv.bahnhof.se] has joined #code
12:10 * gnolam eyes the project's todo list.
12:10
< gnolam>
Geometry for beta simulationMedium25%M
12:10
< gnolam>
[...]
12:10
< gnolam>
Order potassium-rich fertilizerMedium25%H
12:10
< gnolam>
Dig up frogsMedium0%M, H
12:11
< Tamber>
o.o
12:11
<@Namegduf>
You have an interesting project.
12:12 Kindamoody is now known as Kindamoody|out
12:14
< AnnoDomini>
Why are you digging up frogs?
12:15
< Tamber>
Because it's more interesting than working on the code?
12:17
< gnolam>
Because they should be about done by now.
12:17
< AnnoDomini>
Psh.
12:27
< gnolam>
They are simulated frogs (TL dosimetry phantoms), buried in a suitably contaminated patch of Swedish wetland (with a known soil composition and radionuclide distribution).
12:28
< gnolam>
They're the physical control to verify the accuracy of the simulations.
15:26 Stalker [Z@3A600C.A966FF.5BF32D.8E7ABA] has quit [Ping timeout: 121 seconds]
16:40 Derakon [chriswei@8E7DA3.11EB2E.8356BF.B82ACB] has joined #code
16:40
< Derakon>
Okay, clearly this is a normal thing, but I can't find any articles on why it is so.
16:40
< Derakon>
Why can't we mix 32-bit and 64-bit libraries/programs/etc.?
17:09 Stalker [Z@26ECB6.A4B64C.298B52.D80DA0] has joined #code
17:26 Reiver [orthianz@9C034E.E649EA.3194C7.8381A3] has quit [Client closed the connection]
17:26 Reiver [orthianz@9C034E.E649EA.3194C7.8381A3] has joined #code
18:02
< gnolam>
Different pointer size assumptions. Emulation modes.
18:02 * gnolam stabs wx.lib.masked.
18:03
< gnolam>
Was it /really/ necessary to use your own, non-native styles for those controls? :P
18:13
< Derakon>
Gnolam: it's very irritating, because wx only has 32-bit libraries, which means I can't upgrade my program to 64-bit.
18:13
< Derakon>
Which in turn means that I can't open the huge datasets my users are generating.
18:16
< Derakon>
Okay, second question. I have a worker thread that needs to request new data from its creator. What's the best way to handle passing that data off so the worker blocks until it's available?
18:23
< Derakon>
Right now the worker passes itself to the parent, then blocks until the parent has modified fields in the worker.
18:23
< Derakon>
Which feels really hackish to me.
18:46
< gnolam>
Wut? There are 64 bit wx libraries under Windows at least.
18:54
< Derakon>
Not on OSX, though, because they're stuck in Carbon land.
18:57 Vornucopia [NSwebIRC@C888DE.7F9621.E9EB68.2EC12E] has joined #code
19:17
< gnolam>
You wouldn't happen to know if you can do antialiased drawing to DCs in wxPython, would you?
19:51
< Derakon>
Um, not off the top of my head, but worst-case you can always make an OpenGL canvas and draw whatever you like to it.
19:52
< Derakon>
(That is, "I don't know if you can do it", not "I don't think you can do it")
20:18 Kindamoody|out is now known as Kindamoody
20:48 * Vornucopia hunts down the last of the styling problems, then prepares to figure out what IE and Opera are doing wrong.
20:53
< ToxicFrog>
Derakon: re mixing 32 and 64 bit: do you mean "within a program", or "within a system"?
21:07 Kindamoody is now known as Kindamoody|shower
21:07
< Derakon>
TF: within a program.
21:08
< Derakon>
E.g. I want to use 64-bit Python and Numpy, but am stuck with 32-bit WX libraries.
21:27 Kindamoody|shower is now known as Kindamoody
21:38 * Vornucopia fixes stupid random generation errors: Math.random() * n is not an integer.
21:43
< simon_>
does someone assume that?
21:44 * TheWatcher readsup
21:44
< Vornucopia>
I did.
21:45
< Vornucopia>
For about, oh, half an hour, until I went "oh that's why I'm getting batshit 'array' indexes"
21:45
< TheWatcher>
Dera: can you have a 64 bit server sat in the background to do the dataset wrangling, and put the client part in the code with your 32 bit UI, and communicate using some appropriate protocol?
21:46
< Derakon>
Eeerrrr...if I'm to go with a client/server approach I'd just stick the entire program server-side and have people use it via an SSH tunnel.
21:46
< Derakon>
The program purpose is to visualize large datasets.
21:46
< TheWatcher>
fairynuff
21:51 Vornucopia [NSwebIRC@C888DE.7F9621.E9EB68.2EC12E] has quit [[NS] Quit: Page closed]
22:15 Rhamphoryncus [rhamph@C06FE3.F5723C.BE3FEB.9D4666] has quit [Client exited]
22:30 AnnoDomini [annodomini@D553D1.9D4909.B9D09F.0C9BA3] has quit [[NS] Quit: leaving]
22:39 Kindamoody is now known as Kindamoody[zZz]
22:56
< Derakon>
Sigh.
22:56
< Derakon>
WX devs not bothering to update their libraries has reinforced my boss's belief that Mac computers are not suitable for heavy-duty processing.
22:57
< Derakon>
Despite the fact that the Cocoa API has been available for, what, over a decade now, and the WX devs simply haven't gotten around to switching yet.
22:57
< McMartin>
Haet wx
22:57
< McMartin>
Though to be fair AFAICT only Qt4 is acceptable on this count.
22:58
< Derakon>
Does Qt do native UI widgets?
22:59
< McMartin>
Native-looking but not truly native, IIRC.
22:59
< McMartin>
And only fairly recent Qt4 versions at that
22:59
< McMartin>
Prior to... 4.5? I think?
22:59
< McMartin>
It was all Carbon too
23:00
< Derakon>
Yeah, Adobe doesn't want to update Photoshop to Cocoa either.
23:00
< McMartin>
4.6, says our local Qt expert
23:00
< McMartin>
Qt4 also has the lowest spiders/functionality ratio of any full GUI lib I've ever developed for
23:00
< McMartin>
There are still spiders
23:00
< McMartin>
But I found there were fewer
23:01
< Derakon>
Wikipedia says "Recent versions of Qt use the native style APIs of the different platforms to query the platform for the desired appearance of the Qt controls", which I'm not certain I fully understand.
23:01
< Derakon>
But this is apparently distinct from just pretending to be the native widgets.
23:02
< McMartin>
Yes
23:03
< ToxicFrog>
Derakon: AIUI, that means "they don't use native widgets, but they ask the host system what they should look like rather than guessing"
23:04
< ToxicFrog>
I should probably check out Qt someday.
23:06
< McMartin>
Yeah
23:07
< McMartin>
It also means that if you use a window system disassembler like (on Windows) Spy++, you'll get a bunch of "that's a framebuffer." "That's a frame full of framebuffers."
23:07
< McMartin>
And then it draws the likenesses of the true widgets on that.
23:19
< ToxicFrog>
..this may explain why Qt seems to have exceptionally bad performance when X forwarded
23:28
< McMartin>
It is hardly unique in this, though; every cross-platform widget toolkit with remotely acceptable appearance seems to do this.
23:28
< McMartin>
(This is a large part of why Swing looks less assy than AWT - Swing does the "everything's a canvas" thing and AWT throws OS components together and hopes they actually work right)
23:36
< ToxicFrog>
Due to my usage patterns, my sample set here basically consists exclusively of GTK, Qt, and Athena apps.
23:37
< McMartin>
Athena I'm unfamiliar with
23:37
< McMartin>
IIRC GTK basically requires you to redesign the UI for each target OS if you don't want it to look like ass, and it doesn't even begin to try to handle OSX.
23:37
< ToxicFrog>
Athena is the xlib widget set.
23:38
< McMartin>
Wait, I have Pidgin and Spy++ right here
23:38
< ToxicFrog>
Typically only seen these days on very old apps.
23:38
< McMartin>
GTK also does this.
23:38
< ToxicFrog>
Does what?
23:38
< McMartin>
All The Same Window, Drawn Differently
23:38
< ToxicFrog>
Also, "redesign the UI for each target OS" whut
23:38
< McMartin>
Each widget is "GDMWindowTopLevel" or "GDMWindowChild"
23:39 shade_of_cpux is now known as cpux
23:39
< ToxicFrog>
Um. What OS is this?
23:39
< McMartin>
In, for instance, AWT, or Eclipse's SWT, you have to redo your whole layout on each OS because the widgets have different minimum and preferred sizes, and because ever using a non-preferred size for any "normal" UI component looks ridiculous.
23:39
< McMartin>
Windows XP vs. Windows 7 vs. GNOME desktop vs. KDE desktop, mainly.
23:40
< McMartin>
There's a reason nobody uses AWT for anything.
23:40
< ToxicFrog>
I'm terribly confused now and I think you're having two conversations at once and I'm only having one.
23:40
< McMartin>
Hm.
23:40
< McMartin>
Which one do you think you're having?
23:41
< McMartin>
"redesign the UI for each target OS" is "the reason everything's a framebuffer is because widget layouts tend to be otherwise nonportable, for reasons I never fathomed but which experience cannot deny."
23:41
< McMartin>
Kind of a side bit.
23:41
< ToxicFrog>
Aah.
23:41
< ToxicFrog>
And what OS is reporting everything as a GDMWindow*?
23:41
< McMartin>
Windows.
23:42
< McMartin>
I've opened up the Window tree for Pidgin in Spy++, and the total window is "gdkWindowToplevel" and it is then nested at least three deep with nothing but "gdkWindowChild", for buttons, lists, menus, and combo boxes alike.
23:42
< McMartin>
This is not the way something made with MFC or WinForms works.
23:43
< McMartin>
Those names are usually things like "Button" or "ReBarWindow32" or
23:43
< ToxicFrog>
Aah.
23:44
< McMartin>
(True to its name, every widget in Win32 is in fact a "Window" of some kind. The "Window class" indicates what it thinks it is.
23:44
< ToxicFrog>
Do you know of a spy++ equivalent for linux?
23:45
< McMartin>
I don't. It would have to be at minimum X specific and it *might* have to be window manager or even Desktop Environment specific
23:45
< McMartin>
I don't know which bit of the GUI stack is responsible for that in the normal Linux workflows.
23:45 * ToxicFrog does a bit more research
23:46
< McMartin>
I think XCode has Mac's but I don't know what it's called or how it's used.
23:47
< McMartin>
This is another case where my expertise is pretty Windows-specific, but also a place where Windows often has the advantage because "but you have the source! you don't need reverse engineering tools!" never flies
23:47
< McMartin>
And it doesn't fly to the point that reversing tools are part of MS's own distributed SDKs.
23:47
< McMartin>
(Spy++ is part of MSVS)
23:48
< ToxicFrog>
"wininfo" seems kind of similar but not as powerful.
23:50 * TheWatcher notes that, as far as he remembers, GTK+ does the same on linus (run the program in gdb/ddd, and you can inspect the whole lot there)
23:50
< McMartin>
I'm not even positive X has a concept of a "window class"
23:51
< TheWatcher>
*linux
23:51
< TheWatcher>
(ie: the stuff Spy++ is showing under windows is equivalent to wha tI remember on linux)
23:51
< ToxicFrog>
Ok, it looks like on a fundamental level, X11 also has Everything Is A Window; all XLib knows about is generic rectangular drawing regions.
23:52
< ToxicFrog>
Xt (which Xaw and Motif are built on) provides a basic framework for heirarchical widget libraries but doesn't actually implement any widgets.
23:52
< ToxicFrog>
GTK and Qt talk to xlib directly and use their own framework.
23:53
< ToxicFrog>
This kind of shoots down my theory as to why Qt performs so badly in NX, since it looks like GTK does pretty much the same thing.
23:53
< McMartin>
Hm. Yes.
23:53
< McMartin>
Also, yeah, that also explains why Linux has no concept of what Java called "heavyweight widgets"
23:53
< McMartin>
Swing would use Xlib directly, while AWT there, IIRC, forwarded to Motif, which talks to Xt which talks to Xlib.
23:54
< McMartin>
On OSes that *have* widget toolkits as part of the OS (Win32 and OSX), Qt and GTK say "I would like a bunch of rectangular drawing regions plz", which AWT called a "canvas" and which I don't think otherwise has a set name
23:54
< McMartin>
And then they presumably use those canvases the same way they'd use what Xlib handed them.
23:55
< ToxicFrog>
"canvas" is not universal but seems to be common (GTK uses it as well).
23:55
< McMartin>
I tend to rage a little at this because when there's a UI automatic framework in the OS, it tends to play astoundingly poorly with GTK or Qt.
23:56
< McMartin>
(Qt a little less so, since as of 4.6 it is in fact wrapping Cocoa and so some of it you can hit with standard automation tools, but you can't, for instance, suck data out of text boxes because the OS doesn't know it *is* a text box)
23:57
< TheWatcher>
huh, I'd never thought of that one
23:57
< ToxicFrog>
"UI automatic framework"?
23:57
< McMartin>
OSX and Windows let you fabricate UI events and post them to widgets.
23:57
< ToxicFrog>
Oh, s/automatic/automation/?
23:57
< McMartin>
Yeah
23:57
< McMartin>
Sorry
23:58
< McMartin>
While you can say "activate that menu item", for instance, "click that button" tends to require mouse takeover and such on a GTK or Qt app instead of "activate that button".
23:59 * ToxicFrog nods
--- Log closed Tue Apr 19 00:00:24 2011
code logs -> 2011 -> Mon, 18 Apr 2011< code.20110417.log - code.20110419.log >