| | Logging Started : Sun May 17 12:21:32 EDT 1998 |
|
Jordy:
|
oh
|
|
Jordy:
|
hey
|
|
graydon:
|
heya. Just waiting around..
|
|
graydon:
|
I'm compiling a new IRC client in the background..
|
|
Jordy:
|
i'm listening to that heresy project report
|
|
graydon:
|
what is that?
|
|
Jordy:
|
c|net trial of linux
|
|
Jordy:
|
for a month
|
|
graydon:
|
which distro are they using?
|
|
Jordy:
|
redhat and caldera
|
|
Jordy:
|
sorta interesting listening to problems they have :)
|
|
Jordy:
|
http://www.news.com/Radio/Features/0,155,205,0.html
|
|
Jordy:
|
16:00?
|
|
Jordy:
|
i thought it was 18:00
|
| | graydon has set the topic: "Berlin development meeting starting at 18:00 today" |
| | graydon has set the topic: Berlin development meeting starting at 18:00 today |
|
graydon:
|
eep
|
|
Jordy:
|
fixed a few problems in that source tree.. sorta forgot to remove some stuff which i had when I made stubs directories
|
|
Jordy:
|
should actually build now :)
|
|
graydon:
|
ok. You're editing the tree in CVS right?
|
|
Jordy:
|
those pdf documents you added to the source tree are huge :)
|
|
Jordy:
|
yeah, just committed it
|
|
Jordy:
|
last night, when you were adding those pdf docs
|
|
graydon:
|
yeah, I know. I was thinking maybe I shouldn't, but then it seems like everyone needs 'em anyway.
|
|
graydon:
|
Maybe I'll make a separate module, so you can ignore 'em at your leisure..
|
|
Jordy:
|
doesn't really bother me... just the people who have a little slower modems
|
|
Jordy:
|
what's this whole cos directory..
|
|
Jordy:
|
looks like program management, execution, destruction, etc
|
|
graydon:
|
cos is corba-services. They're standardized interfaces for doing things that everyone does with distributed objects, so that everyone's implementations can interoperate.
|
|
Jordy:
|
mmm, ok
|
|
graydon:
|
so I am starting to shift our system to use them in places where it's appropriate. Like -- cloneable is much better done as lifeCycleObject, and obtain<> is much better done as genericFactory.
|
|
graydon:
|
It's more verbose, but at least it's a standard.
|
|
graydon:
|
besides, in many cases the corba design is a lot more flexible than ours. They have more brains.
|
| | graydon ;) |
|
Jordy:
|
haha, ok then...
|
|
graydon:
|
blast! I wish gnome would make up their mind where they put things...
|
|
Jordy:
|
my copy still won't run correctly... i should double-check that I compiled everything berlin links against w/ _REENTRANT
|
|
graydon:
|
how do you mean "not correctly"? What kind of error?
|
|
Jordy:
|
it cores.. brings up a window in X... then disapears :)
|
|
graydon:
|
what bpp are you running X in?
|
|
Jordy:
|
i forgot the error exactly
|
|
Jordy:
|
1152x864@16bpp
|
|
graydon:
|
that's why. ggi 0.0.9 considers "default" == "8bpp" and cores in any other depth.
|
| | graydon sighs |
|
Jordy:
|
oh geez
|
|
graydon:
|
it might be something else though. Are you running name service?
|
|
Jordy:
|
of course :)
|
|
graydon:
|
got "export WARSAW=`pwd`" done?
|
|
Jordy:
|
yeah, we should fix that :)
|
|
graydon:
|
yeah I know
|
|
graydon:
|
heh
|
|
Jordy:
|
since I actually have the root path in the make config script
|
|
graydon:
|
I implemented genericFactory last night to do widget loading on demand instead of all at startup.
|
|
graydon:
|
Hope to have it debugged in a few days.
|
|
Jordy:
|
we might actually want to start using the registry
|
|
graydon:
|
yeah
|
|
Jordy:
|
for plugin paths and what not
|
|
graydon:
|
yeah that would be keen. Also, notice in the corba docs there is an exernalization standard as well as a "properties" standard.
|
|
Jordy:
|
that way we can have directories for company names.. clean up namespace a bit... it will get cluttered :)
|
|
Jordy:
|
i did read about that, sort of an introspection thing...
|
|
Jordy:
|
question, when berlin actually runs
|
|
graydon:
|
Partly. Part of that is interface Repo, which is in a HUGE 9 meg pdf I didn't put in cvs.
|
|
Jordy:
|
what is it supposed to do? :)
|
|
graydon:
|
if you're lucky, right now, it'll open up a window and then sit there. There are no widgets. It's waiting for things to do...
|
|
Jordy:
|
i've gotten past all the loading of plugins and init of ggi and what not... just it's always cored when ggi runs :)
|
|
graydon:
|
yeah, the core dump is unfavourable. It's supposed to sit there. A grand accomplishment.
|
| | graydon grins |
|
Jordy:
|
what is the plan, to corba'ize some 2d and 3d routines
|
|
graydon:
|
We gotta write some stupid looking widgets just to make sure it works
|
|
Jordy:
|
or something a bit higher-level
|
|
Jordy:
|
yeah, i can make a button, bout the easiest widget to make :)
|
|
graydon:
|
and then, yeah, export everything from the low level to the very-high-level.
|
|
Jordy:
|
a gray box... not hard :)
|
|
graydon:
|
yeah
|
|
graydon:
|
I'm hoping my new book on postscript will be here by then, and we can make sure there's nothing important left out of the interfaces.
|
|
Jordy:
|
I'd like to move any header files which will be used in other apps to the top level include, since I'm just going to cp -R that to /usr/Berlin/include
|
|
graydon:
|
I got all of fresco yesterday
|
|
graydon:
|
oh, yeah, by all means. I was wondering if the plan to isolate the idl was still real
|
|
Jordy:
|
-rw------- 1 jordy admin 1985294 May 15 11:12 Fresco-980515.tar.gz
|
|
Jordy:
|
that one?
|
|
graydon:
|
mm.. maybe.. lemme see
|
|
Jordy:
|
i was going to isolate the idl, but it turned out to be a bit harder than I thought :)
|
|
graydon:
|
yeah
|
|
graydon:
|
it's slow, but kinda cool
|
|
graydon:
|
you can do nifty things like run the graphics editor recursively.
|
|
graydon:
|
But it's got lots of stable code we can rip off.
|
|
Jordy:
|
I haven't tried it, read about it a while back though
|
|
Jordy:
|
it's all GPL'ed?
|
|
graydon:
|
it's under a "released from research department of big companies" kinda license. It looks to me like it's free, you just have to put their name at the top of the source fiels and promise not to say theie companies are responsible.
|
|
graydon:
|
s/theie/their/
|
|
Jordy:
|
oi, i hate BSD style licenses for that.. clutter the poor source :)
|
|
Jordy:
|
I need to get a syntax highlighting editor which understands IDL
|
| | graydon has set the topic: "Berlin development meeting starting at 18:00 (gmt) today" |
| | graydon has set the topic: Berlin development meeting starting at 18:00 (gmt) today |
|
graydon:
|
mm. you can throw emacs into cc mode and it's pretty close. There's an idl mode floating around but I don't have it.
|
|
Jordy:
|
what are we doing for a string class
|
|
Jordy:
|
i saw some of the unistr stuff you had in text/
|
|
Jordy:
|
we still have the unicode lib from the old source tree.. it works fairly well
|
|
graydon:
|
there's 2 parts to that. There's strings and glyphs themselves, and there's buffers / editor classes
|
|
Jordy:
|
right... but I'm talking more about when we pass strings around applications
|
|
graydon:
|
the buffer class I think anoq is writing.
|
|
graydon:
|
strings are either 16 or 32 bit wide integer sequences. I just put a corba wrapper on them..
|
| | anoq (root@msx-0b-1-18.1033.cybercity.dk) has joined channel #berlin |
|
Jordy:
|
ahh
|
|
anoq:
|
hey Graydon, Jordan - is that you?
|
|
Jordy:
|
we need a way toa ccess the registrar... what do you suggest...
|
|
graydon:
|
yeah. Hey anoq
|
|
anoq:
|
Testing nickname...
|
|
anoq:
|
Do I have a nickname?
|
|
graydon:
|
jordy. I was thinking it's be *real* snazzy if someone opened up the omniNames service and hacked the registrar on the side, so you are just talking about persistent corba names.. that's the simplest I can think of.
|
|
Jordy:
|
ircing as root == bad :)
|
|
Jordy:
|
gray: i was thinking the same thing, because CORBA already has that interface
|
|
graydon:
|
yeah, and omniNames is actually a lousy implementation omho.
|
|
graydon:
|
s/omho/imho/
|
| | groby (gorby@dslip05.canit.se) has joined channel #berlin |
|
Jordy:
|
then we need to start distributing our own OmniNames :)
|
|
graydon:
|
we'll need a small curses client too, in case your video card craps out and you need to edit the registry.
|
| | jones (jones@130.228.228.34) has joined channel #berlin |
|
graydon:
|
jordy: omni is GPL. why not?
|
|
jones:
|
hi all, anoq you made it!
|
|
graydon:
|
hey cool, everyone's an hour early ;) or did I calculate my local clock wrong?
|
|
Jordy:
|
no, it's 1800 GMT now :0
|
|
Jordy:
|
Sun May 17 13:06:04 EDT 1998
|
|
anoq:
|
yup! Just got ircII up and running a few minutes ago...
|
|
Jordy:
|
i'm in GMT-5
|
|
graydon:
|
heh. Ok. score one for linux locales. My machine translates me to GMT-4, but it's 13:06 for me too..
|
|
anoq:
|
Time is 7pm here as planned...
|
|
jones:
|
anoq: ok, I was testing an account on another machine for you, no need for that now. I'll be right back
|
| | Signoff: jones (Leaving) |
|
graydon:
|
oop. no, just my machine at work. Debian gets it right.
|
|
Jordy:
|
alrighty, so where do we start.
|
| | jones_ (jones@pm21-59.image.dk) has joined channel #berlin |
|
Jordy:
|
mmm, i'm the only one with uppercase
|
| | Jordy is now known as jordy |
|
jones_:
|
ok, back
|
| | jones_ is now known as jonas |
|
graydon:
|
ok then I guess we'll get started?
|
|
anoq:
|
go ahead...
|
|
jonas:
|
is anyone logging?
|
|
graydon:
|
The agenda I'm suggesting for today is as follows:
|
|
graydon:
|
(and I'm already logging)
|
|
graydon:
|
1. exceptions
|
|
graydon:
|
2. text layout, especially the recently released libGFH
|
|
graydon:
|
3. double buffering, backing store, and incrimental redisplay
|
|
graydon:
|
4. shared video buffers
|
|
graydon:
|
5. sound
|
|
graydon:
|
6. security
|
|
graydon:
|
7. sessions / contracts / pinging, whatever is needed to identify
|
|
graydon:
|
and recover from network failure or failure of a remote host.
|
|
graydon:
|
8. metrics, paths and geometry abstractions
|
|
graydon:
|
9. deploying "developer" services, like notices of cvs commits and
|
|
graydon:
|
rpms / debs of required software
|
|
graydon:
|
10. integration with Corba Services (if we have time)
|
|
graydon:
|
except I think the order is all screwed up. But those are the issues.
|
|
anoq:
|
where do we start?
|
| | graydon has set the topic: "berlin: administrivia" |
| | graydon has set the topic: berlin: administrivia |
|
jordy:
|
let's head out with exceptions, what exactly is the issue?
|
|
graydon:
|
First of all, has everyone got the new cvs tree?
|
|
jonas:
|
in two secs... :)
|
|
jordy:
|
i should probably be in linux, i'll be back in about, 10 seconds :)
|
|
graydon:
|
nothing much changed, I just want to make sure we're all talking about the same sources
|
|
anoq:
|
Yes - got the CVS, and it looks really good!
|
|
graydon:
|
exceptions and debugging
|
| | graydon has set the topic: "berlin: exceptions and debugging" |
| | graydon has set the topic: berlin: exceptions and debugging |
| | graydon has set the topic: "berlin: exceptions and debugging" |
| | graydon has set the topic: berlin: exceptions and debugging |
|
graydon:
|
I've added a small new class called "debug" which I've put some enumerated categories in
|
|
graydon:
|
it contains a simple debugging-logger. If we all use this instead of cerr, you'll be able to selectively see groups of logically related debugging messages.
|
|
graydon:
|
or compile the behaviour out in a production version
|
|
jordy:
|
there we go :)
|
|
graydon:
|
anyone have a problem with that? We did it at work and it's very handy.
|
|
jordy:
|
mmmm, seems fine to me, what kind of information does it give?
|
|
anoq:
|
I am looking at it now... seems OK
|
|
graydon:
|
jordy: nothing now, it's just a wrapper for cerr. It can do something more advanced in the future maybe
|
|
jonas:
|
ehh, graydon did you put the COSS document in the cvs?!! The 8 megs??
|
|
jordy:
|
looks fine
|
|
graydon:
|
not the whole thing. I left out a couple chapters. I understand it's too big, I'll move it to a new module so you don't have to check it out.
|
|
jonas:
|
graydon: ok, fine
|
| | ixx (ixx@pm3-1-084.lub.arn.net) has joined channel #berlin |
|
graydon:
|
ok. Next then I wanted to make sure everyone knows that corba *has* an exception mechanism, meaning that interfaces can throw exceptions.
|
| | Signoff: ixx (Read error to ixx[pm3-1-084.lub.arn.net]: EOF from client) |
|
graydon:
|
across a network boundary
|
|
jonas:
|
maybe just link from the webpages? anyway offtopic right now
|
|
graydon:
|
that's important, because exceptions are a very good way of handling strange conditions and controlling failures.
|
|
graydon:
|
core-dumping is not really what we're looking for.
|
|
anoq:
|
I think we should have a seperate file for defining berlin-exceptions
|
| | ixx (ixx@pm3-1-084.lub.arn.net) has joined channel #berlin |
|
graydon:
|
anoq: exceptions can be derived from one another, so there should be some intentional design to how they work, yes
|
|
jonas:
|
exceptions are defined in each IDL file, righ?
|
|
anoq:
|
For my string-objects I need (at least) rangeCheckError, textFormatError
|
|
graydon:
|
there are 2 kinds: IDL exceptions and C++ implementation exceptions. We use both.
|
|
anoq:
|
notEnoughMemoryError would also be _very_ handy
|
|
ixx:
|
hello
|
|
jordy:
|
OutOfMemory sounds good
|
|
graydon:
|
IDL exceptions get compiled to C++ exceptions
|
|
jordy:
|
what does new throw when we run out of ram?
|
|
graydon:
|
ixx hi
|
|
anoq:
|
ixx: who are you?
|
|
graydon:
|
jordy: there are a large number of "standard" corba exceptions, which cover the cases mentionned here so far and much more.
|
|
jordy:
|
i'm not used to exceptions under C++, only Java... they look the same
|
|
anoq:
|
jordy: I hope it throws an exception, but not sure...
|
|
smkl:
|
jordy: i guess it just returns 0
|
|
jordy:
|
the only real difference looks to be the catch (...) fallthrough
|
|
graydon:
|
The specs in the "doc" directory outline them.
|
|
ixx:
|
ummm i am taylorcc@arn.net or zeus@tomserver.phys.ttu.edu
|
|
ixx:
|
brb
|
|
graydon:
|
C++ lets you throw anything you like, since it's not a pure O-O language, but normally your exceptions are classes just like java.
|
|
graydon:
|
Also the throw/catch contract is optional -- generates a warning. Unlike java.
|
|
jordy:
|
gotcha...
|
|
graydon:
|
But please, if you know something can throw, obey the warning!
|
|
anoq:
|
Can IDL exceptions be subclassed as in C++?
|
|
jordy:
|
what happens when something throws an exception and it's not caught under C++?
|
|
graydon:
|
anoq: good question. afaik yes but that's just cause it would be stupid otherwise. Not sure.
|
|
anoq:
|
jordy: the app exits...
|
|
graydon:
|
jordy: if it was declared in IDL, it'll propagate through the ORB to the caller, who has the option to catch it there.
|
|
jordy:
|
ooo, that's clean
|
|
graydon:
|
jordy: otherwise the runtime cals abort();
|
|
graydon:
|
abort is less clean.
|
|
jordy:
|
alright... just curious...
|
|
anoq:
|
OK... I was thinking C++ without CORBA... sorry
|
|
graydon:
|
Ok, so the procedure here is, if you're writing a new interface, to declare a new exception if you think it's a special kind, or to declare that your interface throws one of the common corba exceptions if you expect it might.
|
|
jonas:
|
should we not use a special throw, not C++ throw, but a ORB method for throwing, while catching is standard?
|
|
graydon:
|
For instance, out of memory is a corba exception. So is range-error.
|
| | jones (jones@pm21-59.image.dk) has joined channel #berlin |
| | jonas has left channel #berlin |
| | jones is now known as jonas |
|
graydon:
|
jones: no, the orb puts an exception handler in place during the upcall for any IDL-generated exceptions. You do a C++ throw, the C++ ORB which called up catches and returns.
|
|
jordy:
|
can we define a standard way to catch exceptions for things like range-error? So in the future everything generates the same standard looking error message instead of each class having to do it?
|
|
anoq:
|
I could subclass range-error to textRangeError, if possible...
|
|
ixx:
|
anoq, i sent u an email several weeks ago about NSXKit
|
|
graydon:
|
jordy: yeah. I'd like a message catalogue ideally.
|
|
jordy:
|
DisplayException(ExceptionType) sort of thing
|
|
anoq:
|
ixx: I don't think I recieved it then... mail me again...
|
|
graydon:
|
jordy: yeah, it can even go in the debug class, for that matter ;)
|
|
graydon:
|
jordy: use a hugely polymorphic virtual method.
|
|
jordy:
|
hahah.. that would be interesting to say the least
|
|
ixx:
|
anoq, it seems noone is working on it anymore.... that would be nice to have on berlin.... or libGWT
|
|
anoq:
|
jordy and graydon: Sounds good... this is how Delpi does it
|
|
jonas:
|
ixx: what would you like to have in LibGWT?
|
|
graydon:
|
OK. so the other issue is that I want to make sure everyone's been thuroughly lectured on the fact that you don't *have* to catch exceptions at a local level. If there are multiple logically sound ways of handling the problem you'd best leave it up to the caller and just rethrow.
|
|
anoq:
|
ixx: NSXKit is the OpenStep API implemented in XLib. It was meant to be ported as NSXKit backend, so that it's just an XLib backend for GNUStep
|
|
ixx:
|
jonas, i would like the back-end for gnustep-gui to be ported to libGWT
|
| | graydon temporarily becomes a rabid OO-design zealot |
|
jordy:
|
right, we want to delegate the responsibility to the developer's application if possible... since a lot of the time it's their fault :)
|
|
anoq:
|
ixx: We could make a berlin-backend for GNUStep...
|
| | graydon goes back to normal |
|
ixx:
|
anoq, yes it would be nice to have a backend on berlin or libgwt
|
|
jordy:
|
alrighty, i think we've beaten exceptions to death
|
| | graydon has set the topic: "berlin: text layout, especially the recently released libGFH " |
| | graydon has set the topic: berlin: text layout, especially the recently released libGFH |
|
jordy:
|
i say we steal the layout code from netscape :)
|
|
anoq:
|
ixx: Can we discuss GNUStep/NSXKit later?
|
|
graydon:
|
I spent a *long* time this week nattering with a guy at work who is an insane sypography fan, the results of which are now in cvs under /src/berlin/text
|
|
graydon:
|
s/sypography/typography/
|
|
ixx:
|
anoq, yes sorry
|
|
jordy:
|
i read a bit of it
|
|
jonas:
|
are there any reasons for not using libGFH?
|
|
anoq:
|
graydon: the stuff in text looks really good too!
|
|
graydon:
|
It's a little convoluted and I want to make sure people (a) like it, (b) know how it works
|
|
graydon:
|
jonas: oh, we will be using libgfh. I have also been talking to andrew about it (the guy who wrote libgfh)
|
|
jordy:
|
ok, you have three peices it looks like, the font, the glyph and the string
|
|
graydon:
|
It's just that libgfh only handles fonts.
|
|
jordy:
|
you feed the string into the font which gives us a glyph? :)
|
|
graydon:
|
jordy: close. You feel the string through a mapper which makes a glyph sequence. Glyphs are abstract. You feel the glyph through a font mapper and a font cascade, and get a little picture, which you then cache and display.
|
|
graydon:
|
s/feel/feed/
|
| | graydon can't type today |
|
jordy:
|
ok, i've heard about different methods of caching on a character by character basis, or a word by word basis
|
|
graydon:
|
The reason for having a middle level of abstract glyph is that every font indexes using different names of glyphs
|
|
jordy:
|
if we have the word 'the' 5 times, we don't need to feed it through the font mapper 5 times do we?
|
|
anoq:
|
how about support for different colours of font? It doen't seem to support that - or is that just current fg+bg color?
|
|
graydon:
|
jordy: I'm thinking we're doing charcter-by-character caching. You go through the mapper 3 times for the first "the" and then just hit the cache thereafter.
|
| | jonas is amazed by the new repo layout, well done! |
|
jordy:
|
anoq: oh geez... let's stick with b&w for now :)
|
|
graydon:
|
mm. we have to keep color text in mind
|
|
jordy:
|
well, ok
|
|
jordy:
|
let's do it the XML way then
|
|
anoq:
|
current fg+bg would be good... perhaps globally
|
|
jordy:
|
break the document's text away from the document's format
|
|
jonas:
|
I don't think colors are the worst part, probably easy to do, but more about Unicode support and antialiasing
|
|
anoq:
|
jordy: What's XML?
|
|
graydon:
|
we also have to keep in mind a nasty side effect of kerning and subpixel spacing, which is that you need to keep as many cached images as you have grey levels in your anti-aliasing routine, unless you do anti-aliasing after positioning on the screen.
|
|
jordy:
|
XML is a replacement for HTML, you have the text string as one peice, and then you have it's formatting (color, etc) as another peice
|
|
jordy:
|
i'm not saying implement an XML parser.. but more on the lines of, let's render the text first
|
|
jordy:
|
apply the color second
|
|
graydon:
|
jordy: yeah. XML / XSL will likely play a big role in our formatting model
|
|
graydon:
|
jordy: and I totally agree with color being separated
|
|
jordy:
|
gray: yeah..
|
|
jordy:
|
technically it'd be easier to just corba'ize mozilla :)
|
|
jordy:
|
i mean, it has everything we want right?
|
|
graydon:
|
cause otherwise we have to store a separate cache image for each transparency and color combination. Our cache would crash the computer.
|
|
anoq:
|
jordy: less flexible though..
|
|
jordy:
|
it can layout graphics, text, etc
|
|
graydon:
|
jordy: may well do that
|
|
jordy:
|
Mozilla does have an XML parser too
|
|
jordy:
|
it just needs the XSL parser...
|
|
graydon:
|
they have james clar's XML parser. It's freely available, separately.
|
|
jordy:
|
yep...
|
|
jordy:
|
if anyone here has looked at the mozilla source, it's broken down into nice corbafiable peices, the layout engine, the parsers, everything :)
|
|
graydon:
|
jordy: they can already do somepretty advanced stuff. A guy from work was at their conference and they showed stylized XML pages (using CSS1, mind you)
|
|
jordy:
|
hmmmm
|
|
ixx:
|
there will be a new layout engine in the next release though
|
|
jordy:
|
ixx: yeah, raptor.. i've used it
|
|
jordy:
|
it's blindingly fast
|
|
graydon:
|
yeah. I'd like to see raptor.
|
|
anoq:
|
graydon, jordy: We could use code from mozilla, but how about my string APIs?
|
|
graydon:
|
anoq: hrm, it's been a while sorry. Lemme look again.
|
|
jordy:
|
anoq: i don't see it interfering at all
|
|
anoq:
|
Users has to be able to edit the text...
|
|
ixx:
|
off to lunch
|
| | Signoff: ixx (BitchX: the ONLY bug-free client (yeah right).) |
|
graydon:
|
yeah, it looks good.
|
|
jordy:
|
ok... we have a user with a text box open
|
|
jordy:
|
the user types, letters appear
|
| | Signoff: groby (cIRCus 0.43 - http://www.nijenrode.nl/~ivo/circus/) |
|
anoq:
|
graydon: I just enhanced it today, making it even better - not committed to CVS yet..
|
|
graydon:
|
As for rendering glyphs, the suggestion I got was that when an edit takes place, you should run the word beign edited through your mappers again to re-compose combining characters and ligatures and stuff.
|
|
graydon:
|
anoq: you can get a nice fast implementation of a small buffer-gap string editor from libgtk. It's exactly what we should be aiming for.
|
|
graydon:
|
anoq: unless you want to try to extract it from vim or xemacs ;)
|
|
anoq:
|
graydon: I'll have a look... I am still aiming at multi-client text-editing though...
|
|
graydon:
|
that's ok, you can lock down the object during an edit. I have no problem with that.
|
|
jordy:
|
the only problems i see happening are when we render text... that whole left->right right->left thing with different languages still confuses me :)
|
|
anoq:
|
graydon: multi-client displays too...
|
|
graydon:
|
jordy: there's a complete bi-directionality algorithm in the unicode book. I'll implement it if nobody else has the code or the book..
|
|
jordy:
|
that'll work
|
|
graydon:
|
anoq: you might want to look at subj-observer in cvs.
|
|
anoq:
|
graydon: did so, and I intend to use it for the string stuff too...
|
|
graydon:
|
anoq: I put in an "auto-update" method you can flip to turn off updating of an observer during a bulk edit.
|
|
anoq:
|
graydon: cool!
|
|
graydon:
|
ok..
|
|
graydon:
|
we done with text?
|
|
jordy:
|
alright, that'll work.. we can worry about the higher-end stuff of rendering graphics & text together when we are farther along
|
|
graydon:
|
yeah, and we're gonna look at raptor for that too
|
|
jordy:
|
yeah, i'd say so graydon
|
| | graydon has set the topic: "berlin: double buffering, backing store, and incrimental redisplay" |
| | graydon has set the topic: berlin: double buffering, backing store, and incrimental redisplay |
|
jonas:
|
regarding backing store I'm planning on making it much like X in libGWT
|
|
graydon:
|
ok, I"ve been reading up on how the kernel maps memory around, and it is possible to mmap() video memory any old place we like, including into the client's address space (if they're local)
|
|
graydon:
|
but that's skipping ahead to the next issue a little. they're related.
|
|
graydon:
|
Any buffers we have will be in one of four places. Video memory held by the server, video memory held by the client, system memory by the server, and system memory by the client.
|
|
graydon:
|
the question is how to minimize copying
|
|
graydon:
|
while letting the client get whatever they want accomplished
|
|
jordy:
|
well
|
|
jonas:
|
Do we really need direct access to video mem from Berlin? I mean we have ggi libraries for that, right?
|
|
graydon:
|
jonas: yes, directbuffer will be the mechanism because it chields us from byte ordering or memory layout.
|
|
graydon:
|
that's part of libggi
|
|
graydon:
|
s/chields/shields/
|
|
jonas:
|
yes, but with libgwt for window management, libgfh for fonts, and all those other libs, should we not "just" use them?
|
|
graydon:
|
jonas: this is very related to the progress you're making with gwt..
|
|
graydon:
|
jonas: we should when it's possible. You forget they have no network or process transparency
|
|
graydon:
|
jonas: or perhaps they are process transparent. You are the one working on them...
|
|
graydon:
|
jonas: them .. it. GWT.
|
|
graydon:
|
Can multiple processes connect to it right now?
|
|
jonas:
|
The way I see it, every system running Berlin should have GGI (and libs) under it, then the Berlin window object uses a gwt window
|
|
jonas:
|
graydon: no, and that's not quite the way I'm imagining it.
|
|
graydon:
|
jonas: agreed. How does gwt work? I haven't seen it since mentalboy was coding it back in feb.
|
|
jonas:
|
Say a client opens a remote window, it should be the responsibility of the remote Berlin Display Server to create a remote Berlin Window Object, which in turn has a "local" GWT window
|
|
anoq:
|
graydon, jonas: are we sure to have GGI + libs in say BeOS, WinNT etc?
|
|
graydon:
|
anoq: that's the GGI's plan
|
|
anoq:
|
graydon: cool...
|
|
jordy:
|
yeah, libggi is getting ported every which way
|
|
jonas:
|
graydon: I've been a little busy with school work, but I have been working on line-clipping, next thing was Cyrus-beck algo, which allows for polygonal regions
|
|
graydon:
|
jonas: ok, cool. Now how does GWT manage those windows internaly? With callbacks to redraw portions, or with backing store?
|
|
jonas:
|
I'm planning on a X like behaviour, backing-store as an attribute of the window and otherwise an exposure event
|
|
graydon:
|
jonas: it's significant because there will be clients who want direct access to their window's buffer.
|
|
graydon:
|
jonas: ok, that's sane.
|
|
jonas:
|
ok, I guess a byte sequence is going to cut it :)
|
|
graydon:
|
jonas: I didn't want expose events, but I'm beginning to see it as an inevitability for all those wusses with < 64 megs on their video cards.
|
| | graydon grins |
|
jordy:
|
64 meg video cards, geez
|
|
jonas:
|
yeah, why can't we all have 256MB ram and UMA Æ=
|
|
anoq:
|
jonas: fine with me :)
|
|
anoq:
|
I mean - I would like if everybody had :)
|
|
jonas:
|
The main point here is that libgwt is used locally on the Display server, which in turn has Window Objects which are connected to local as well as remote clients
|
|
graydon:
|
jonas: ok, I also want you to keep in mind that mmap()ing part of that memory is a possibility to enhance throughput.
|
|
graydon:
|
although duncan has stated (don't know if you caught it) that there's a shared-memory omni-orb transport floating around too. That might do it.
|
|
jordy:
|
yeah, i think he said it was in development
|
|
jonas:
|
nope, it was internal :)
|
|
jordy:
|
yeah, that's what i meant :)
|
|
jordy:
|
in development @ orl :)
|
|
graydon:
|
we can probably count on that helping though.
|
|
graydon:
|
orl seem like a nice bunch of people
|
|
jonas:
|
not sure, how to do the direct buffer access, but I'm sure it will be solved, at least locally, how can we best do it remote?
|
|
graydon:
|
jonas: if VNC is GPL, I say we look over their protocol. I mean, nobody would seriously run quake in a window on a remote machine and expect it to work fast...
|
|
graydon:
|
QuakeGL, that's another issue.
|
|
jordy:
|
of course not
|
|
jordy:
|
well, if we could port Mesa
|
|
graydon:
|
jordy: I hope that will be the case.
|
|
jordy:
|
even then... i mean, you are talking about a ton of calls per second :)
|
|
graydon:
|
it should fit in nicely with GWT
|
|
graydon:
|
well, yeah, but you'd at least have a chance.
|
|
jordy:
|
you might be able to get away with a slower style game, like tetris however :)
|
|
graydon:
|
I suspect there are fewer GL calls than there are putpixels.
|
|
jordy:
|
but for the most part, people will probably running large things
|
|
jordy:
|
like compilers and web browsers
|
|
graydon:
|
Ok, well I'd like jonas to provide a web page to help people track GWT, and also make some source available soon, but other than that does anyone have any problems with his way of doing windows?
|
|
graydon:
|
jonas: at your leisure, those things. Obviously if you're in school you have other constraints.
|
|
jonas:
|
currently http://lin01.vejlehs.dk/~jones/libgwt.html :)
|
|
jordy:
|
sounds fine and dandy to me... :)
|
|
graydon:
|
sound
|
| | graydon has set the topic: "berlin: sound" |
| | graydon has set the topic: berlin: sound |
|
jonas:
|
I have 5 weeks left in school, and next week another GWT developer returns
|
|
jordy:
|
alright, uhm... what about it? :)
|
|
jordy:
|
are we talking network sound?
|
|
graydon:
|
free for all. Any ideas on the table.
|
|
graydon:
|
we haven't discussed it yet and we'll need it eventually
|
|
jordy:
|
well, basic sound events would be nice
|
|
jonas:
|
Hmm, sound registration (in registrar ala windows) and NAS?
|
|
anoq:
|
ALSA = Advanced Linux Sound Architecture - anybody knows it?
|
|
jordy:
|
something like that, linked into our exception handler for errors :)
|
|
graydon:
|
ok. do we want server-side sound objects for buffering?
|
|
jordy:
|
anoq: i heard of it, they want to replace OSS right?
|
|
anoq:
|
jordy: I think I read so - yes..
|
|
jordy:
|
i think network sound is probably unrealistic for the quality audio people use
|
|
anoq:
|
jordy: How about an mpeg3 stream?
|
|
jordy:
|
well
|
|
jordy:
|
mpeg3 could do it
|
|
graydon:
|
also, you can send a sound to a display server once and then re-trigger it.
|
|
anoq:
|
Except that mpeg3 is _very_ slow to compress (I've heard)
|
|
jordy:
|
make mp3 our official sound format and we won't have to worry about that :)
|
|
graydon:
|
or send load a synthesis package and send it instructions
|
|
anoq:
|
graydon: good idea! - Like reusing an image
|
|
jordy:
|
well
|
|
graydon:
|
midi events, etc.
|
|
jordy:
|
mmmm, maybe we need a sound server :)
|
|
graydon:
|
that's how sound cards work nowadays, they store waves on the card and trigger them with certain parameters
|
|
graydon:
|
using a hardware mixer.
|
|
anoq:
|
graydon: yearh... MIDI is good - but slow IRL...
|
|
jordy:
|
mmm
|
|
jordy:
|
well
|
|
graydon:
|
midi tops out at 33kbps on the wire. So it's quite realistic over a modem.
|
|
anoq:
|
At least MIDI is standard...
|
|
jordy:
|
ok, most sound events will just be events... small 1-2 second clips
|
|
jordy:
|
which will play on whatever machine the user is typing on
|
|
graydon:
|
real-audio... mp3 ... midi ...
|
|
jonas:
|
anoq: but more than one MIDI standard!
|
|
anoq:
|
I think MIDI has a max freq.
|
|
graydon:
|
midi is not a sound transfer spec, it's an event triggering spec.
|
|
anoq:
|
jonas: I don't think so - only different speeds
|
|
graydon:
|
although there's a sample-dump extension to it
|
|
graydon:
|
there are differing standards for the "standard" instrumnt map.
|
|
anoq:
|
graydon: I think it has to have a special frequency - at least for synths
|
|
jonas:
|
anoq: Did Roland not make their "own", standard midi, general midi? Maybe I'm just rambling, but I had problems with keyboards
|
|
graydon:
|
anoq: what do you mean by "special frequency"? It's an async digital protocol that tops out around 30kbps
|
|
jordy:
|
i guess there is a good chance that people are going to want network sound... so they can have their mp3 player on the server and hear it on their workstation... are there any network sound protocols out there?
|
|
graydon:
|
jonas: yeah, there's "general midi" and also yamaha's "XS"...
|
|
jordy:
|
i thought midi was dead :)
|
|
anoq:
|
jonas, graydon: Ohhh stop! You are confusing things... General Midi etc. are only standards for where the instruments are placed - it has nothing to do with the MIDI protocol!
|
|
jonas:
|
jordy: NAS - Network Audio System, the only one I've used
|
|
graydon:
|
jordy: It's got some replacement ideas floating around but it's still the standard.
|
|
jordy:
|
yeah, will CORBA stream? :)
|
|
graydon:
|
anoq: I know, but that's important too.
|
|
jonas:
|
anoq: I rest my case, I just know the problem, not really the reason
|
|
graydon:
|
jordy: not inherently. You'd have to write a streaming system on top of it == slow. Might as well just use corba to negotiate the stream in a standard streaming protocol.
|
|
jordy:
|
because if we just made a CORBA interface... we'd have to send bytes
|
|
jordy:
|
cut up the song
|
|
anoq:
|
graydon: If you send a sample of a scream - which instrument it that?
|
|
jordy:
|
send 30 bytes
|
|
smkl:
|
i have heard NAS for linux doesnt work
|
|
graydon:
|
anoq: in midi, you say "note 32, instrument 44, volume..." .. unless you're talking about sample-dump
|
|
anoq:
|
Btw: MIDI is only for triggering sounds... we need something else to send the samples
|
|
jonas:
|
smkl: I wouldn't really call my experience a success but it "kinda" played .wav but that may be better now
|
|
smkl:
|
there is another one in deveplopment, check http://www.netcom.com/~ericmit/EsounD.html
|
|
smkl:
|
that was on the gnome list also
|
|
graydon:
|
Yeah. Gnome has incorporated a thing called "enlightened sound daemon", I think that's what you're talking about. We should look at it.
|
|
graydon:
|
Ok. So no firm ideas on sound.
|
|
graydon:
|
No religious commitments to any way of doing things.
|
|
anoq:
|
graydon: I think MIDI is a good "trigger" :)
|
|
graydon:
|
anoq: I agree. It's nice and standard.
|
|
graydon:
|
You can feed it straight into /dev/sequencer and your sound card (or synth) takes over.
|
|
anoq:
|
graydon: Yup!
|
|
jonas:
|
we have /dev/sequencer, /dev/audio, I want /dev/mp3 :)
|
|
jordy:
|
hahaha
|
|
jordy:
|
/dev/mp3.. full blown mp3 decoder in the kernel
|
| | graydon knows this because last year he wrote a linux sequencer ;) |
|
graydon:
|
/dev/mp3 isn't too implausible. I bet people sell the chips..
|
|
jordy:
|
i've heard some MPEG decoders can handle MP3...
|
|
jonas:
|
yup, but I'd rather have hardware encoding, decoding is something like 0.9 cpu
|
|
graydon:
|
jordy: didn't even know they used the same technology. mpeg is just the name of the standards group, no?
|
|
jordy:
|
gray: MP3 == MPEG1 layer 3
|
|
jordy:
|
it's part of MPEG 1 "standard"
|
|
graydon:
|
Oh, ok.
|
|
jordy:
|
what i meant to say is that I've heard of some DVD hardware mpeg decoders which can decode MPEG1.3 quite well...
|
|
anoq:
|
jordy: isn't mpg3 also MPEG2 layer 3?
|
|
jordy:
|
anoq: that i wouldn't know :)
|
|
jordy:
|
i do know it's 1.3 tho :)
|
|
jonas:
|
anoq: not in the usual sense,
|
|
anoq:
|
hmmm
|
|
graydon:
|
bah. ok. next topic...
|
|
jonas:
|
ok
|
|
jordy:
|
yeah, whats next
|
| | graydon has set the topic: "berlin: security" |
| | graydon has set the topic: berlin: security |
|
graydon:
|
security
|
|
jordy:
|
ooo, my favorite topic
|
|
graydon:
|
grrrr
|
|
anoq:
|
bring in the cops!
|
| | graydon winces when he considers security systems |
|
jordy:
|
yeah, declare berlin a soverign nation... any security breakin attempts against it will be considered an act of war
|
| | jordy grins |
|
graydon:
|
I've put the document describing how corba thinks security should be done in the /doc/corba-docs directory
|
|
jonas:
|
Anyone know what COSS has to say about this?
|
|
graydon:
|
It's huge and extremely complex
|
|
graydon:
|
10 times the size of any other chapter
|
|
graydon:
|
They just settled on a standard in corba 2.2
|
|
jordy:
|
yeah, well... i've heard NT is going w/ Kerberos for security auth
|
|
graydon:
|
NT uses a kinda hacked up form of kerberos, yeah.
|
|
anoq:
|
Kerberos? Enlighten me....
|
|
jonas:
|
jordy: Is kerberos exportable to outside us?
|
|
graydon:
|
Kerberos is a very powerful security system developed at MIT
|
|
graydon:
|
It's somewhat complex though
|
|
graydon:
|
I've administered it and it's quite paranoid. Doesn't deal well with systems whose clocks are a few minutes out of sync, etc.
|
|
jordy:
|
jonas: should be... otherwise ms is gonna have a hard time selling NT5 :)
|
|
graydon:
|
I'd like to have that level of security possible, but I don't want to force it. It'll confuse too many people.
|
|
jordy:
|
well
|
|
graydon:
|
I mean, kerb is just too much for a home user.
|
|
jordy:
|
we could always go the SSL route
|
|
jordy:
|
very simple authentication using certs
|
|
anoq:
|
graydon: agree
|
|
graydon:
|
I'll be honest and say I haven't even *read* the COSS document yet.
|
|
jordy:
|
i have to boot into windows to read pdf's :)
|
|
graydon:
|
There's many levels to security
|
|
graydon:
|
jordy: get acroread
|
|
jordy:
|
you kidding? fonts under X looks choppy, hurt my eyes to read :)
|
|
anoq:
|
jordy: get xpdf from debian.org - it's faster than acrobat reader!
|
|
graydon:
|
there's "you can't read this", there's "I know who you are", there's "I can prove you did this"... etc.
|
|
graydon:
|
jordy: turn on anti-aliasing. It's fine.
|
|
jordy:
|
mmm
|
|
graydon:
|
jordy: well, for some suitably lax definition of the word "fine"
|
|
jordy:
|
audit trails and authentication
|
|
jordy:
|
audit trails are a bit mmm
|
|
jonas:
|
acroread is very nice, just need 125-150%
|
|
jordy:
|
moer complex than home users care about :)
|
|
jordy:
|
more rather
|
|
graydon:
|
jordy: agreed, and COSS is very concerned about corporate things (they like the word "enterprise")
|
|
anoq:
|
xpdf has ugly fonts too...
|
|
jordy:
|
authentication again can be done one of 800 ways
|
|
jordy:
|
what exactly are we trying to secure against however?
|
|
graydon:
|
Yeah, now what COSS did is break up "compliance" in to multiple levels. Like, if you're a wuss you can just implement "level 1" securty. I don't know what that means but it's promising. I'd like to interoperate if possible.
|
|
jonas:
|
"illegal" object access I guess, What if someone gets a IOR to one of your objects....
|
|
graydon:
|
jordy: people attacking your machine, deleting your files, pretending they're you, reading your mail, intercepting your widgets, you name it.
|
|
jordy:
|
mmmm
|
|
anoq:
|
graydon: intercepting widgets? Sounds fun :)
|
|
jordy:
|
ok, that might be bad :)
|
|
jonas:
|
Changing the NameService!
|
|
anoq:
|
Good way of getting some more widgets on the system :)
|
|
jordy:
|
so we need basic authentication... ip based is out
|
|
graydon:
|
anoq: well, if I intercept your text widget and send every event you type to myself as well as the app, you'll be none too pleased.
|
|
anoq:
|
graydon: I guess not...
|
|
jordy:
|
i'll have to read COSS
|
|
jordy:
|
to see how they implement basic security
|
|
graydon:
|
so I guess I'm recommending that we all get a beer and sit down to read COSS
|
|
graydon:
|
sometime when we don't mind blowing 10 hours reading legalese
|
|
jordy:
|
yeah, it'll take a few hours
|
|
jordy:
|
6 pack
|
|
jordy:
|
:)
|
| | graydon grins |
|
graydon:
|
ok. we'll talk more after having read it.
|
|
jordy:
|
alrighty, what's next
|
| | graydon has set the topic: "berlin: sessions / contracts / pinging" |
| | graydon has set the topic: berlin: sessions / contracts / pinging |
|
jonas:
|
heh, happyli in Denmark we have 12-packs!
|
|
graydon:
|
Again, this might be the sort of thing COSS has something to say about
|
|
jordy:
|
why do we need to ping anything, doesn't the OS take care of socket destruction?
|
|
graydon:
|
but we need a way of knowing when a remote app dies
|
|
graydon:
|
jordy: omni dynamically allocates sockets.
|
|
jordy:
|
it dies when the remote computer tells us that the socket is dead, i'm sure corba must sense that
|
|
graydon:
|
jordy: after 30 seconds idle sockets close.
|
|
jordy:
|
really?
|
|
graydon:
|
yep
|
|
jordy:
|
oh geez
|
|
jordy:
|
well, we need a little echo then :)
|
|
graydon:
|
yeah. I was thinking the app could keep a single object for it's session, to avoid pinging all its widgets.
|
|
jonas:
|
sounds good, I know a DCOM / CORBA comp. that bashed DCOM for pinging, so there must be a CORBA alternative!?
|
|
jordy:
|
gray: right, just a little areYouAlive() method
|
|
graydon:
|
jonas: well, the trick is anything other than a ping assumes the client has a feasable way of telling you it's finished. What if someone just drops a bomb on the client and they are gone from earth?
|
|
jordy:
|
a bomb, geez... how about something a bit more feasible, someone hits the power by accident :)
|
|
graydon:
|
jonas: it's either the client pings the server to update a watchdog timer, or the server pings the client every time it gets curious.
|
|
jordy:
|
we should ask duncan about that
|
|
graydon:
|
jordy: what if the meteor from deep impact lands *RIGHT ON THE CLIENT*?
|
|
jordy:
|
hahaha
|
|
anoq:
|
graydon: amusing :)
|
|
jonas:
|
I guess no insurance will cover it :)
|
|
anoq:
|
Heh - no ;)
|
|
jordy:
|
i think for right now... an areYouThere() method would be the easiest...
|
|
graydon:
|
yeah, ok, so we'll see what duncan has to say about it, and unless he (or COSS) has any better idea we'll make a little session management interface.
|
|
jonas:
|
ok
|
|
jordy:
|
something like that
|
|
jordy:
|
what's next
|
| | graydon has set the topic: "berlin: metrics, paths and geometry abstractions" |
| | graydon has set the topic: berlin: metrics, paths and geometry abstractions |
|
graydon:
|
Any postscript hackers around here?
|
|
jonas:
|
speaking of what about printing
|
|
jordy:
|
see, i don't like postscript because every implementation of it (with the exception of openstep)... looks like shit :)
|
|
jordy:
|
i know it's WYSIWYG
|
|
jonas:
|
jordy: ?? LaserJet 4M handles it just fine :)
|
|
jordy:
|
jonas: haha
|
|
graydon:
|
Metrics have to be available to the client app. Period. The client might be a DTP program which is doing some fierce logic about layout.
|
|
graydon:
|
jordy: on the display, yeah. But the imaging model is pretty good.
|
|
jordy:
|
well i display more things than i print :)
|
|
jonas:
|
we could look at ghostview, nobody is planning on reading anything, right?
|
|
graydon:
|
jordy: me too, but we can't write off printing ;)
|
|
jordy:
|
how does the Mac do it?
|
|
jordy:
|
they supposedly have awesome printing abilities
|
|
jordy:
|
actually, come to think of it
|
|
jordy:
|
how many printers have postscript anyway?
|
|
graydon:
|
jordy: many mac apps take the logic inside themselves. But they do (I think) make metrics available to clients.
|
|
jordy:
|
i know the two i have here don't
|
|
graydon:
|
jordy: fewer and fewer. I don't mean to say we *must* use the postscript imaging model. But we need a few things afaik
|
|
graydon:
|
we need transformation matricies
|
|
graydon:
|
subpixel positioning
|
|
graydon:
|
paths
|
|
graydon:
|
and metrics
|
|
anoq:
|
I don't like using postscript for display - only for printing...
|
|
jonas:
|
pdf printers - yum, cat coss.pdf > /dev/printer :)
|
|
graydon:
|
this sort of thing has to be in our imaging model if we're going to work in print at all, as well as if we want to work with new display technologies.
|
|
jordy:
|
i don't like postscript period.... we will just have to have printer drivers... print everything as graphics save us some time :)
|
|
graydon:
|
The question is does anyone here know a damn thing about these?
|
|
anoq:
|
jordy: agree
|
|
graydon:
|
jordy: not an option
|
|
jordy:
|
not me, i print about two things a month.... i've never been interested in that sort of thing
|
|
graydon:
|
jordy: me neither. My printer is currently in on a bookshelf collecting dust.
|
|
jordy:
|
we are just looking for some way to get our onscreen representation to match our printed version right?
|
|
anoq:
|
my Star LC20 printer needs ink!
|
|
graydon:
|
jordy: not just that. If I take something on the screen and stretch it, it has to do something intelligible other than get big and chunky.
|
|
jonas:
|
no matter where _our_ printers are, printing is one of the most important features we _must_ provide, and do it _much_ better than X
|
| | yusef (yusef@199.1.27.58) has joined channel #berlin |
|
anoq:
|
graydon: scalable fonts? true type etc..
|
|
jordy:
|
well... it's something that none of us have any experience in unfortunatly
|
|
yusef:
|
hello
|
|
graydon:
|
scalable fonts still need transformation matrix support to be able to express stretching, rotating, etc. I just want there to be interfaces to represent this sort of stuff.
|
|
anoq:
|
a bitmap image will always get jagged
|
|
graydon:
|
anoq: but a path won't.
|
|
jordy:
|
graydon: we will probably just need to leave it open for now
|
|
graydon:
|
jordy: Ok, then I'm going to pick up a book on postscript & typography and learn.
|
|
anoq:
|
transformation matrixes etc sounds OK - but bypass 'em for display
|
|
jonas:
|
graydon: that's the spirit!
|
|
graydon:
|
anoq: no, the whole point of using a structured drawing editor is that it's shapes not pixels.
|
|
graydon:
|
anyway it's ok, we'll return to the issue once we've learned about it.
|
|
jordy:
|
shouldn't be too hard to implement in the future
|
|
anoq:
|
graydon: I know - a scalable coord-sys then?
|
|
graydon:
|
yeah.
|
|
graydon:
|
scalable, rotatable, deformable -- i.e. transformation matricies.
|
|
anoq:
|
graydon: ok ok ok
|
| | graydon grins |
| | jordy scratches his head |
| | graydon has set the topic: "berlin: deploying "developer" services" |
| | graydon has set the topic: berlin: deploying "developer" services |
|
jordy:
|
like MSDN sorta stuff? :)
|
|
graydon:
|
like a mailing list for CVS commits
|
|
jordy:
|
ahhh
|
|
jordy:
|
we do need a bugs@berlin-consortium.org
|
|
jordy:
|
not sure if that was ever put in :)
|
|
graydon:
|
like debs / rpms of the most recent working things needed to work on the project
|
|
graydon:
|
also GNATS
|
|
jordy:
|
yeah... mmmm
|
|
jonas:
|
A cvs "announce" with a list of changed files and comments is _very_ usefull!
|
|
jordy:
|
that's easy enough....
|
|
graydon:
|
Yeah. You can sort it in your email, and then read over what's been changing.
|
|
jordy:
|
i still have my cvs log thing
|
|
graydon:
|
do you know how to implement that?
|
|
jordy:
|
one sec
|
|
jordy:
|
i'll show you format
|
|
jordy:
|
ergh
|
|
jordy:
|
pulling down logs
|
|
graydon:
|
ok, does anyone know how to make debs or rpms?
|
|
jordy:
|
Sun May 17 06:43:57 1998 graydon
|
|
jordy:
|
* Berlin/src/berlin/cos/Makefile: tweak
|
|
jordy:
|
* Berlin/src/berlin/cos/InterfaceRepo.idl:
|
|
jordy:
|
the basis of corba introspection, as far as I can tell.
|
|
jordy:
|
only problem is it says @jolt :)
|
|
jordy:
|
which is my box :)
|
|
graydon:
|
what's jolt?
|
|
graydon:
|
aah
|
|
jordy:
|
oh, and it gets a little off on formatting
|
|
jordy:
|
like:
|
|
graydon:
|
well whatever. That looks like a good script. Where does it run?
|
|
jordy:
|
* Berlin/src/berlin/messages/subjectChangedMessage.idl,
|
|
jordy:
|
Berlin/src/berlin/messages/redrawMessage.idl,
|
|
jordy:
|
Berlin/src/berlin/messages/keyEvent.idl:
|
|
jordy:
|
Include problems (stubs dirs never made it into tree)
|
|
jordy:
|
graydon: it's rcs2log... i can give you the params
|
|
jordy:
|
it comes with cvs dist
|
|
jordy:
|
it formats 'cvs log'
|
|
graydon:
|
cool. how do we make it hapen automatically?
|
|
jordy:
|
rcs2log -i 4 -l 76 -r -d \>"last week" Berlin | sed -e "s/.cvs.berlin.//g"
|
|
jordy:
|
well, someone could crontab it and just pipe it to sendmail
|
|
graydon:
|
I'll ask the debian cvs maintainer to do so.
|
| | Signoff: yusef (Leaving) |
|
jonas:
|
I'm pretty sure the system we used, send the mail along with a cvs commit, and only those changes were mentioned, should I ask the maintainer?
|
|
graydon:
|
jonas: that's how the one I have at work happens.. I should really ask the CVS guy there.
|
|
jordy:
|
mmm
|
|
graydon:
|
Of course, you got *lots* of mail.
|
|
graydon:
|
one per day might be nicer. Say, only if something changed.
|
|
graydon:
|
ok, well no obvious solutions there. I'll talk to the cvs maintainer for debian. shall we move to the final topic?
|
|
jordy:
|
yeah, that rcs2log command would be once a week
|
|
jordy:
|
yeah, go ahead
|
| | graydon has set the topic: "berlin: new COSS stuff" |
| | graydon has set the topic: berlin: new COSS stuff |
|
graydon:
|
COSS specifies mechanisms for creating, deleting, relating, embedding, copying, moving, etc. compound objects.
|
|
graydon:
|
I've extracted the IDL and put it in the /src/berlin/cos directory.
|
|
anoq:
|
graydon: That can replace cloneable then?
|
|
graydon:
|
I've also implmented a not-yet-debugged GenericFactory along the lines of the demand loader we were considering
|
|
graydon:
|
anoq: yes, lifeCycleObject will replace cloneable.
|
|
anoq:
|
graydon: does it have autorelease too?
|
|
graydon:
|
anoq: not afaik. It has a destroy method.
|
|
graydon:
|
or maybe a "remove" method. Can't recall the name.
|
|
anoq:
|
we should have autorelease I think
|
|
anoq:
|
DOOH! No - it's a network... :(
|
|
anoq:
|
It won't work right
|
|
graydon:
|
you do have to tell an object when you're done with it, and there's some stickyness having to do with multiple people having references to the object we still need to work out.
|
|
jordy:
|
hmmm
|
|
graydon:
|
Not sure. The specs are all in the corba-docs directory. It's verbose.
|
|
anoq:
|
yearh - like how do we return an object from a method without keeping a ref-count on it, and without having to rely on somebody else to free it?
|
|
graydon:
|
Well, it's basically as complex as you have in C++, having to destroy things yourself, only you can't use variable scope to help you.
|
|
anoq:
|
this sucks...
|
|
graydon:
|
One nice part is that the system doesn't core when you dereference a nonexisting object. You get a specific exception which you can handle.
|
|
jordy:
|
well
|
|
graydon:
|
brb (washroom break)
|
|
anoq:
|
graydon: neat
|
| | graydon returns |
|
jordy:
|
any ideas on how to handle it
|
|
jordy:
|
maybe we should force that responsibility on the developer
|
|
graydon:
|
I think ultimately we'd have all the same problems if we *didn't* use COSS, so using their interfaces just saves us having to do the design work ourselves.
|
|
anoq:
|
jordy: only autorealse... :(
|
|
anoq:
|
The best policy would be: Who allocates something has to free it too
|
|
graydon:
|
I'm guessing that this is in some way related to the "sessions" idea we were discussing wrt. pinging dead clients.
|
|
jordy:
|
give programs an ID
|
|
jordy:
|
assign that ID to a list for each object
|
|
jordy:
|
if the ID no longer exists, remove all objects which were registered with that ID?
|
|
jordy:
|
mmm
|
|
graydon:
|
Yeah. If the client dies, you can reap the object. Still lets a long-lived program make serious server-side memory leaks though.
|
|
jordy:
|
we need a grabage collector
|
|
anoq:
|
perhaps autorelease will work if it is treated as a local feature...
|
|
graydon:
|
No worse than a client which bogs down an X server tho.. just don't run the client anymore ;)
|
|
jordy:
|
haha
|
|
jordy:
|
we shouldn't try to promote bad applications
|
|
anoq:
|
I think autorelease can do the trick after all
|
|
anoq:
|
Anyone knows what I am talking about? Seen OpenStep?
|
|
jordy:
|
as far as ID's go, we do have a registry :)
|
|
graydon:
|
anoq: specify what you mean with autorelease, can you?
|
| | jonas is away: (Auto-Away after 10 mins) [BX-MsgLog On] |
|
jordy:
|
i can't remember if i brought this up before, are we going to move the registrar to corba and kill libregistrar?
|
|
anoq:
|
Autorelease is somewhat like release (with ref-count), except that the release doesn't happen until the end of the outer event being processed
|
|
graydon:
|
I don't think we have to *kill* libregistrar, I think you and I were discussing binding its API to COSS name service though.
|
|
jordy:
|
oh yeah, my memory is caputs
|
|
jordy:
|
lemme write that down :)
|
|
graydon:
|
jordy: it's in the log, too.
|
|
jordy:
|
so we want to rip apart omninames
|
|
anoq:
|
autorelease happens before an app starts to process the next event
|
|
graydon:
|
anoq: ok, so, what if we obtain a reference and then store it locally in a variable of the program?
|
|
graydon:
|
jordy: or just politely alter it, yeah.
|
|
anoq:
|
if you obtain a ref you add a ref count, and the autorelease only decrements the ref-count
|
|
graydon:
|
anoq: that's still just a lousy memory leak, and it's the app developers fault, right?
|
|
graydon:
|
anoq: ok, well there's something else to consider
|
|
anoq:
|
no no - no leak. When you are done with your ref, you need to release it too
|
|
graydon:
|
anoq: the corba library allocates memory for the *stub itself* on the client, and that memory is reference counted.
|
|
anoq:
|
but I guess garbage collecting on top would be good
|
|
graydon:
|
anoq: so maybe we can tie into that reference count, and when it's released we can tell the server to decrement its ref-count.
|
|
anoq:
|
sounds good
|
|
graydon:
|
anoq: all we'd have to do is alter the omni object_var type a little (that's the ref-counting one) and then the server would be informed.
|
|
anoq:
|
OK
|
|
jordy:
|
yeah, we need a garbage collector... so at least we can try and keep leaks in check
|
|
anoq:
|
we need to implement the autorelease pool though
|
|
graydon:
|
and in the worst case, when a client dies, our pinging system will notice in a little while and decrement ref counts for all related objects.
|
| | Amphigory (patrick@cx47248-a.nwptn1.va.home.com) has joined channel #berlin |
|
jordy:
|
alright, that makes sense
|
|
graydon:
|
jordy: I'm not sure if mark and sweep is realistic in a networked setting. Maybe.. ref counting works though.
|
|
graydon:
|
Although, java 1.1 has "Distributed Garbage Collection" in its interfaces. I haven't read how that works yet though.
|
|
anoq:
|
We need autorelease + garbage collector then - right?
|
|
anoq:
|
- If garbage collector works...
|
|
graydon:
|
autorelease (meaning the client does useage-count), GC meaning the server goes ref count, and server can group objects by application and pings application periodically, yeah.
|
|
jordy:
|
we will be fairly safe then... unless that meteor hits the display server
|
|
graydon:
|
so now we need to talk to omni people about altering the object_var type a little.
|
|
jordy:
|
then what happens to the client? :)
|
| | graydon grins |
|
anoq:
|
well autorelase is just a local function which says "free this in a while"
|
|
graydon:
|
the client will get a "server is toast" exception when it tries to connect for a call.
|
|
jordy:
|
haha
|
|
jordy:
|
server is toast
|
|
jordy:
|
that should be our error message
|
|
anoq:
|
:)
|
| | Amphigory looks frantically in the CORBA specs for the "server is toast" exception :) |
|
graydon:
|
ServerIsToastException : virtual public FearAndLoathingException
|
|
jordy:
|
of course
|
|
graydon:
|
it's in the section entitles "don't look here"
|
|
Amphigory:
|
graydon: shouldn't you inherit that from the "WindowsNT" object?
|
|
jordy:
|
anyhow
|
|
graydon:
|
s/entitles/entitled/
|
|
graydon:
|
ok I think that's it. Does anyone else have things they want to discuss?
|
|
anoq:
|
I have some questions on the text subject...
|
|
graydon:
|
anoq: go ahead
|
|
anoq:
|
OK - you talked about mozilla, and some other nice code...
|
| | graydon hasn't actually read the mozilla code yet, sigh. |
|
anoq:
|
Are you planning on implementing one big complete: display, store and edit text-object?
|
|
jordy:
|
like a text window object?
|
|
graydon:
|
anoq: erm.. Well there's the obvious optimization that non-editable text has much less code beneath it, so there has to be a separate "just-displayable" text.
|
|
anoq:
|
Coz I intend to separate storage from display/render and edit
|
|
graydon:
|
anoq: yeah.
|
|
graydon:
|
anoq: I agree entirely. They're separate issues.
|
|
graydon:
|
I've just been poking around with the rendering system. Haven;t touched storage or editing yet.
|
|
anoq:
|
OK - I have planned for an optimized display-only situation - but storage is still seperate from display/render
|
|
graydon:
|
yup
|
|
anoq:
|
Also single line text is a seperate case, as well as multi-line, single font/style/color
|
|
Amphigory:
|
anoq: Single line is a seperate case for rendering, but not for storage, ?
|
|
graydon:
|
yeah, layout algorithms are higher than glyph-instance rendering.
|
|
Amphigory:
|
anoq: Shouldn't that be rather...
|
|
graydon:
|
the thing I made just hands back a sequence of little pictures and their metrics.
|
|
anoq:
|
Amphigory: well single line is so simple that it can be all-in-one
|
|
graydon:
|
anoq: I think there are 2 storage cases: editable and non-editable.
|
|
Amphigory:
|
anoq: If you're going to break out rednering and storage for multi-line, I'd do it for single line too... It's more elegant; simple.
|
|
anoq:
|
Single line uses glyph rendering too
|
|
Amphigory:
|
simple += r
|
|
anoq:
|
graydon: There are already in my API :)
|
|
graydon:
|
anoq: cause whether or not it spans multiple lines is a layout issue.
|
|
jordy:
|
yeah, multiple lines sounds like an issue for a widget
|
|
graydon:
|
anoq: yeah, I'm just saying I don't think you need *more* types of storage. 2 is ok.
|
|
anoq:
|
graydon: agree
|
|
anoq:
|
Amph.: agree
|
|
anoq:
|
jordy: agree
|
|
jordy:
|
so what's our course of action from here
|
|
anoq:
|
I think that's all my questions
|
|
jordy:
|
what's the next few things which we need to work on
|
|
graydon:
|
anoq: so we got 2 kinds of text storage, (2x2) = 4 kinds of layout, correct?
|
|
anoq:
|
I have some general questions as well
|
|
graydon:
|
jordy: that was all I had on my agenda for today.
|
|
jordy:
|
gray: nono
|
|
jordy:
|
editing source wise
|
|
anoq:
|
graydon: I don't copy ;)
|
|
anoq:
|
graydon: What do you mean?
|
|
graydon:
|
2 kinds of storage, editable and non-editable. 4 kinds of layout: single-line-editable, single-line-non-editable, multi-line-editable, multi-line-non-editable.
|
|
jordy:
|
doesn't omniNames use the Windows registry in Win32?
|
|
anoq:
|
graydon: Oh yearh... except there's more: with attributes and without attributes - and that goes for both storage and display
|
|
graydon:
|
jordy: yes.
|
|
graydon:
|
anoq: right. so 4 edit types, and 8 display types.
|
|
jordy:
|
so we could start up registrar as it's own process, hack omniNames to use libregistrar to connect to the registry just like it's done in windows?
|
|
anoq:
|
graydon: I think so...
|
|
graydon:
|
anoq: ok. Arranged in a multiple-inheritence hierarchy it's not that bad
|
|
jonas:
|
jordy: only for configuration, like port
|
|
graydon:
|
jordy: yep
|
|
jonas:
|
jordy: or did I misunderstand
|
|
anoq:
|
graydon: I have it already - did you check it?
|
|
jordy:
|
only for omniNames configuration?
|
|
jordy:
|
well
|
|
graydon:
|
anoq: looked but not carefully enough. If that's what you did, I got no problems with it.
|
|
jordy:
|
we need to use the registrar... we have all these paths and what not #def'ed in our source and pulled out of env vars
|
|
anoq:
|
graydon: cool
|
|
graydon:
|
jordy: yeah, that's the wrong way to do it. It should be in one spot.
|
|
jordy:
|
i'd like to replace them with calls to the our registry
|
|
graydon:
|
anoq: you might want 1 more type to throw in there -- text which is a link.
|
|
anoq:
|
graydon: That's for web-browsers right?
|
|
jordy:
|
graydon: what would you suggest
|
|
jordy:
|
what is the best way to access the registry from our corba clients & the display server
|
|
anoq:
|
graydon: It could just be displayed with another colour attribute...
|
|
graydon:
|
jordy: I like the idea so long as we can get at the registry with a text program. I'm not a hardcore unix everything-must-be-text zealot, but it has to become text when you ask.
|
|
jordy:
|
as it is there is a text regedit program... very very basic tho :)
|
|
jordy:
|
but it's linked directly against libregistrar
|
|
Amphigory:
|
graydon: Amen. My biggest peeve with the "microsoft way" is that you have to write a C program for everything. The registry should be "textifiable" to avoid that.
|
|
graydon:
|
anoq: not the point: the link is a specific attribute of a sequence of text --> where it links to, what it does when the link is actuated, etc. Read the W3C's DOM recommendation. Especially important if we use raptor for anything.
|
|
anoq:
|
graydon: Where do I find that?
|
|
graydon:
|
hold on, I'll get it.
|
|
graydon:
|
it's heavily XML-influenced, but I think that's actually a good thing. We should support that model of a document. It's becoming very widely accepted.
|
|
jordy:
|
well, the registry will stay in binary format... but a text program to edit it isn't a big deal... the problem is accessing it from our corba programs... since the registrar currently defines it's own proprietary protocol... i think it'd be better to kill libregistrar, and make the registry corba-aware
|
|
anoq:
|
graydon: I think it's just an attribute to me :)
|
|
graydon:
|
http://www.w3.org/TR/WD-DOM/
|
|
graydon:
|
anoq: if your attributing mechanism is flexible enough, yes.
|
|
graydon:
|
anoq: just make sure your doeument model doesn't violently oppose DOM. It'd be unwise ;)
|
|
graydon:
|
s/doeument/document/
|
|
graydon:
|
jordy: yeah. I'd like registrar to be dumpable too, for backup and reloading purposes.
|
|
anoq:
|
graydon: I'll check it...
|
|
jordy:
|
well that's easy enough gray, it has a database file :)
|
|
jordy:
|
cp registry.dat /mnt/floppy
|
|
jordy:
|
:)
|
|
graydon:
|
dumpable to text.
|
|
jordy:
|
mmm
|
|
jordy:
|
well, that can be done...
|
|
jordy:
|
just run through every key
|
|
jordy:
|
it'll be quite proprietary format however
|
|
jordy:
|
something like:
|
|
graydon:
|
yeah. It's not too bad. It's just that without a recent backup in text form you'd be sunk trying to reconstruct it.
|
|
graydon:
|
jordy: it can also be XML, for that matter.
|
|
graydon:
|
We serialize an object database at work to XML. You can fix errors in it using vi.
|
|
jordy:
|
/System/CORBA/NameService/port,integer,38,owner,permissions
|
|
jordy:
|
something similar
|
|
jordy:
|
comma delimited I assume will work for most
|
|
graydon:
|
I'll push you to use XML cause it's a familliar syntax to many.
|
|
jordy:
|
haha :)
|
|
jordy:
|
but comma delimited is easier to read and transfer back to database format :)
|
|
jordy:
|
it'll get BIG though :)
|
|
graydon:
|
jordy: better editing a big file than telling your boss your configuration system is dead.
|
|
graydon:
|
Anyway that's an issue to deal with once we have it using name service.
|
|
jordy:
|
i guess i'll work on corbafying registrar.. and then make a dat2txt and txt2dat :)
|
|
graydon:
|
cool, that would be great.
|
|
graydon:
|
I still can't think of a good way to get "resolve initial references" for nameservice to work. It's a kludge right now.
|
|
jordy:
|
we only need a few methods
|
|
graydon:
|
jordy: yeah, but the sooner the interface is done, the sooner people get used to using it.
|
|
jordy:
|
getkey, setkey, nextkey, prevkey, keyowner, keyperms, etc
|
|
jordy:
|
i'll take a look at it later today
|
|
jonas:
|
Hopefully registrar will be as easy as TRegistry in Delphi!
|
|
jordy:
|
i've never seen TRegistry
|
|
jordy:
|
what's the API look like?
|
|
graydon:
|
Look at how omniNames works in win32. I bet you can just slide registrar in there.
|
|
jonas:
|
jordy: pretty much as you specified, nice and easy
|
|
jordy:
|
gray: it looks like omniNames for win32 only sets up omniNames configuration
|
|
graydon:
|
jordy: blast!
|
|
graydon:
|
that's no dammed good!
|
|
jonas:
|
not sure, but I think they mentioned it somewhere, registry only contains the /var/omninames/config-file
|
|
jordy:
|
yeah, i think so
|
|
jordy:
|
we'll just have to make our own interface
|
|
graydon:
|
oh well. More work for you ;)
|
|
graydon:
|
hehehehehe
|
|
jordy:
|
i'd like to leave omniNames out of it actually, just because i don't feel like maintaining someone elses work in sync with my changes :)
|
|
jordy:
|
we'll just have class Registrar
|
|
jordy:
|
:)
|
|
graydon:
|
Hey, if you can write something that satisfies /src/berlin/cos/Naming.idl, it's name service as far as I"m concerned.
|
|
jonas:
|
Sounds fine with me
|
|
jordy:
|
Registrar::delete_key()
|
|
jordy:
|
Registrar::add_key()
|
|
jordy:
|
Registrar::next_key()
|
|
jordy:
|
etc
|
|
graydon:
|
well yeah, but it has to export the name service interface, not the registrar interface, right?
|
|
graydon:
|
that's the whole point here.
|
|
jordy:
|
mmmm
|
|
jordy:
|
i'm not sure yet :)
|
|
jonas:
|
hmmm
|
|
graydon:
|
otherwise we're making up something there's a perfectly good standard for. That feels weird.
|
|
jonas:
|
graydon: please explain
|
|
graydon:
|
OK, name service is a method for navigating a graph of nave/value pairs.
|
|
graydon:
|
it's a COS servie
|
|
jordy:
|
key/data pairs :)
|
|
graydon:
|
service
|
|
jonas:
|
name, type -> value
|
|
graydon:
|
yeah. Exactly the same as registrar.
|
|
graydon:
|
So why should we publish a *slightly* incompatible API for doing it, when we could just change the names slightly and be Name=service compatible?
|
|
jordy:
|
I assume cos/Naming.idl isn't complete right? :)
|
|
graydon:
|
That's all there is to providing name service afaik.
|
|
jordy:
|
hmmm
|
|
jordy:
|
well, we have NameComponent, which is fine.. however it lacks ownership/permissions... but it'll work
|
|
graydon:
|
You can make nameComponent return an object which *has* permissions. The objects (values) can be anything.
|
|
jordy:
|
there is no way to back through the keys and i can't find a way to add them :)
|
|
graydon:
|
void bind(in Name n, in Object obj)
|
|
jordy:
|
oh ok then
|
|
graydon:
|
I"m just saying the way you look them up can be standardized.
|
|
jordy:
|
list() is what?
|
|
graydon:
|
void list (in unsigned long how_many,
|
|
graydon:
|
out BindingList bl, out BindingIterator bi);
|
|
jonas:
|
So instead of returning a IOR it should returns e.g. a int or string? Why not just keep the simple API, and what about the Name / Kind pair?
|
|
jordy:
|
jonas: it does name/kind.. it's uhm
|
|
jordy:
|
struct NameComponent {
|
|
jordy:
|
Istring id;
|
|
jordy:
|
Istring kind;
|
|
jordy:
|
};
|
|
jordy:
|
btw graydon, what's with the two character spacing? :)
|
|
anoq:
|
What's Istring?
|
|
graydon:
|
list lets you list everything in a context. Play around with omniNames and nameclt (the client). It's pretty complete.
|
|
jordy:
|
Istring is typedef of string, i guess it will be i18n
|
|
graydon:
|
jordy: what two-character-spacing?
|
|
jordy:
|
graydon: your coding style :)
|
|
graydon:
|
jordy: You mean indentation levels?
|
|
jordy:
|
yeah
|
|
graydon:
|
jordy: I use xemacs CC mode, defaults. Whatever it does is fine by me, as long as it's consistent.
|
|
jordy:
|
mmm, ok
|
|
graydon:
|
I can change it if you like..
|
|
jordy:
|
i'm going to work on this then
|
|
anoq:
|
Is it time for general questions now?
|
|
graydon:
|
anyway yeah, toss the ideas around. You could return IORs which you store as keys in a berlekey DB file.. I don't know.
|
|
graydon:
|
anoq: yeah.
|
|
graydon:
|
s/berlekey/berkeley/ -- man my typing *sux* today.
|
|
jordy:
|
nah, the registrar itself is fine
|
|
anoq:
|
OK - How do we specify constructors to objects in IDL with parameters?
|
|
graydon:
|
haven't looked at it.
|
|
graydon:
|
anoq: Oooh. interesting. Not sure.
|
|
anoq:
|
C++ constructors cannot be called from another language...
|
|
anoq:
|
This will be a problem with terminal.idl/terminal_impl
|
|
graydon:
|
anoq: I always assumed we'd be cloning prototypes and then setting parameters using object methods. Crude, but language-neutral.
|
|
jonas:
|
anoq: speaking of, what about making derived objects in another lang.?
|
|
graydon:
|
hee hee.
|
|
graydon:
|
brb
|
|
anoq:
|
It has a terminal_impl(ggi_visual_t vis); constructor...
|
|
anoq:
|
jonas: Is this a problem? You specify interfaces in IDL...
|
|
anoq:
|
jonas: You have a complete interface-inheritance-tree in every language
|
|
anoq:
|
jonaes: only implementations are language-local :)
|
|
graydon:
|
anoq: yeah, the thing is IDL doesn't actually have *any* way of constructing an object. It's only for their interfaces. It's got no statements, just declarations.
|
|
jonas:
|
IIRC, keyEvent.cc gets linked with event.cc? What is keyEvent.cc was Java and event.cc was C++?
|
|
graydon:
|
anoq: there are genericFactories though
|
|
jordy:
|
mmm
|
|
graydon:
|
yeah
|
|
graydon:
|
that's how you do it.
|
|
anoq:
|
graydon: what are those?
|
|
anoq:
|
jonas: You would have to construct the object the CORBA-way...
|
|
graydon:
|
interface GenericFactory {
|
|
graydon:
|
boolean supports(in Key k);
|
|
graydon:
|
Object create_object(
|
|
graydon:
|
in Key k,
|
|
graydon:
|
in Criteria the_criteria)
|
|
graydon:
|
raises (NoFactory, InvalidCriteria,
|
|
graydon:
|
CannotMeetCriteria);
|
|
graydon:
|
};
|
|
graydon:
|
That's what I implemented last night, only I'm currently *ignoring* criteria. But you could pass criteria in to a constructor that way.
|
|
anoq:
|
graydon: What is Key?
|
|
jordy:
|
are the C bindings in CORBA 2.2 any cleaner by chance? man they are ugly looking right now :)
|
|
graydon:
|
key is the name of the object
|
|
graydon:
|
or, the object-type, I should say.
|
|
anoq:
|
graydon: OK - a string?
|
|
graydon:
|
jordy: don't know about the C bindings. Don't know if there *are* official C bindings or just ILU bindings..
|
|
graydon:
|
anoq: I think it's a sequence of strings.
|
|
jordy:
|
hmmm
|
| | Signoff: Amphigory (Leaving) |
|
jonas:
|
graydon: I believe 2.x has official C bindings
|
|
graydon:
|
jonas: whew. There's a lot of linux hackers who would really hate us if they had to use C++.
|
| | graydon grins |
|
anoq:
|
speaking of languages... I also have an idea:
|
|
jordy:
|
haha, unix is 95% C as it is... people would loathe us :)
|
|
anoq:
|
I think we should make a language-local library for each programming language...
|
|
jordy:
|
althought at least C++ is more accepted than ObjC...
|
|
jordy:
|
i feel sorry for those poor GNUStep people :)
|
|
graydon:
|
anoq: erm. We should keep that as small as possible.
|
|
anoq:
|
This library would already consist of rect_util, and soon my range_util
|
|
graydon:
|
anoq: if you do that, the bindings don't really look the same after a while.
|
|
jordy:
|
in the future, once we get our base done... we should probably attempt something visual
|
|
anoq:
|
jordy: Careful what you say... I'm an old GNUStepper ;)
|
|
jordy:
|
anoq: sorry, but come on.. admit ObjC isn't exactly the most accepted language in the world, and it's not getting any better either :)
|
|
graydon:
|
jordy: yeah. I am going to make a greyBoxWidget as soon as jonas produces some working GWT code ;)
|
|
anoq:
|
jordy: I know... It's pretty nice though...
|
|
jordy:
|
grayBoxWidge would be cool too :)
|
|
graydon:
|
Ok, well we've been here for 3 hours.. are there other major issues short of all the reading and programming we have to do?
|
|
anoq:
|
Yes...
|
| | graydon has set the topic: "berlin: question period" |
| | graydon has set the topic: berlin: question period |
|
jonas:
|
is anyone playing around with a new theme for our webpages?
|
|
anoq:
|
I need an enum-type for compare-functions - it should have {below, equal, above}. I think we should have a global type for this, since it's quite useful...
|
|
graydon:
|
jonas: I'd like to make a modular build of the website.
|
|
jonas:
|
modular build??
|
|
graydon:
|
jonas: makefiles, perl, stylesheets, cpp, anything to save hand-modifying all the pages.
|
| | jordy points graydon at php |
|
graydon:
|
anoq: I guess. We should be using iterators wherever possible though.
|
|
graydon:
|
jordy: not available on all of our mirrors.
|
|
anoq:
|
graydon: What?
|
|
graydon:
|
It has to be static pages
|
|
jordy:
|
damn those mirrors :)
|
|
anoq:
|
graydon: It's for a compareToString -method...
|
|
graydon:
|
anoq: I'm just saying, bidirectional iterators and sorted containers are more readable, in general, than hand-coded loops.
|
|
anoq:
|
gray
|
|
jordy:
|
anyone want to write some generalized routines? btrees and what not?
|
|
anoq:
|
graydon: It's just for comparing the text in my string-objects..
|
|
graydon:
|
anoq: ok. Lexicographic compare is out, though. It has to be a replacable sorter.
|
|
graydon:
|
jordy: between glib and stl I think we have ourselves covered.
|
|
anoq:
|
graydon: fine... it's for the result :)
|
|
graydon:
|
anoq: ok
|
|
jordy:
|
yeah, thank goodness for glibc
|
|
jonas:
|
ok, my disk is getting really annoying, see you later
|
|
graydon:
|
bye jonas!
|
|
anoq:
|
jordy: I could use a dictionary-object...
|
|
graydon:
|
thanks for coming
|
|
jordy:
|
jonas, make bugs@
|
|
jordy:
|
:)
|
|
jordy:
|
anoq: haha
|
| | Signoff: jonas (jonas has no reason) |
|
jordy:
|
anoq: maybe someone will corbafy spell for you :)
|
|
graydon:
|
jordy: hey man, we're gonna need that someday.
|
|
jordy:
|
but uhm, right now... we need simpleBox :)
|
|
anoq:
|
jordy: No kidding! I am planning to steal one from GNUStep though, and port it from Obj-C - if that's OK with you ;)
|
|
jordy:
|
i don't know man
|
|
jordy:
|
ObjC... ugh :)
|
|
graydon:
|
simpleBoringDrabDoesNothingGreyBox -- can the intrepid berlin project do it?
|
|
anoq:
|
jordy: I'll port it - promise...
|
|
jordy:
|
i'm about scream/bitch/yell about ggi 0.1.0 :)
|
|
jordy:
|
someone said 7 weeks
|
|
jordy:
|
that's just silly :)
|
|
jordy:
|
i mean, a box is one thing
|
|
jordy:
|
i want a button :)
|
|
graydon:
|
jordy: you daredevil
|
|
jordy:
|
i want... dare i say it
|
|
jordy:
|
a button i can move my mouse over and
|
|
jordy:
|
and
|
|
jordy:
|
click
|
| | graydon is in awe |
|
jordy:
|
but we can't exactly do that without events from ggi :)
|
|
graydon:
|
I know. Pisses me off that we can do so much plumbing and still get stiffed with a simple black screen.
|
|
jordy:
|
i have a dream :)
|
|
jordy:
|
well
|
|
jordy:
|
maybe we can make it a gray screen
|
|
jordy:
|
:
|
|
graydon:
|
We'll need the plumbing someday though. Good to work on it anyway.
|
|
anoq:
|
graydon: Yearh... someday things will evolve rapidly :)
|
|
graydon:
|
If jonas can get me something that at least pretends to be libgwt we can use 0.0.9 for the time being
|
|
jordy:
|
yeah i guess.. but my skills lie in higher level implementation, i'll work on registrar then, at least i can contribute :)
|
|
graydon:
|
ok.
|
|
anoq:
|
I stick with the string-objects for now...
|
|
jordy:
|
but if ggi 0.1.0 doesn't come out soon, i will go ape shit on the ggi mailing list ;)
|
|
graydon:
|
cool. I'll read and implement what I have from COS. other comments & questions? I actually *want* to end the meeting sometime ;)
|
|
anoq:
|
Btw: One final remark:
|
|
jordy:
|
nah, i think that's it for me
|
|
jordy:
|
damn you anoq
|
|
anoq:
|
I have read about properties in the corba-docs dir in CVS...
|
| | graydon has set the topic: "berlin: anoq holds innocent people hostage" |
| | graydon has set the topic: berlin: anoq holds innocent people hostage |
|
graydon:
|
yes
|
|
anoq:
|
:) :)
|
|
anoq:
|
It seems very promising... I just read the first pages...
|
|
graydon:
|
If I can get properties IDL files to compile, you'll be the first to know
|
|
jordy:
|
properties, that would be (in java terms) introspection right? like, figure out what vars/methods i can set in the object from the outside?
|
|
graydon:
|
It would be excellent for user editing, etc.
|
|
anoq:
|
It's like Delphi properties, and can be used for implementing an object-inspector... :)
|
|
anoq:
|
jordy: Correct!
|
|
graydon:
|
jordy: not quote that detailed. It's more like a unified way of saying "here world, these are the ways you can customize me"
|
|
jordy:
|
like
|
|
anoq:
|
graydon: Yes!
|
|
jordy:
|
good for pluggable l&f
|
|
anoq:
|
graydon: Precisely.. I think it looks good...
|
|
graydon:
|
OK. I don't know enough about it to say how far we'll go with that, but it's an important document. Let's all read it.
|
|
jordy:
|
one of these years, when we get far enough
|
|
anoq:
|
jordy: No - for editing the colour of your box! :)
|
|
jordy:
|
i will actually implement my base berlin design look
|
|
jordy:
|
actually, i should change it
|
|
graydon:
|
anoq: if you want to make your text attributes correspond to COSS properties, I think that would be good.
|
|
jordy:
|
i like rhapsody DR2's look better, just without that lame global menu bar, i want one for each window damnit
|
|
anoq:
|
graydon: I'll have a look....
|
|
graydon:
|
jordy: yeah rhapsody is *sweet*
|
|
jordy:
|
i have Dr1 intel installed on my second drive
|
|
anoq:
|
jordy: You are not an old Amiga fan then?
|
|
jordy:
|
anoq: i've never used amiga to tell you the truth
|
|
anoq:
|
.... heh... and I have got OpenStep for Intel installed :)
|
|
jordy:
|
the only time i've even seen one is screen shots someone sent me :)
|
| | graydon was an amigaist long ago in the mists of time |
|
jordy:
|
graydon: yeah, that rhapsody is sweet
|
|
jordy:
|
too bad it can't read mac disks
|
|
jordy:
|
well, DR1 died everytime i tries :0
|
|
jordy:
|
tried even
|
|
graydon:
|
jordy: picky picky. Man, the new macs don't even *have* floppy drives!
|
|
jordy:
|
your kidding right
|
|
jordy:
|
no floppy drives?
|
|
anoq:
|
Don't worry! I will replace OpenStep with BeOS, as soon as I recieve a version with SCSI support... :)
|
|
graydon:
|
jordy: nope. Look at the imac. Look closely. Big CD tray, no floppy. You can buy a USB floppy, extrenal. STUPID!
|
|
jordy:
|
oh my lord...
|
|
graydon:
|
ok. I'm closing the log and going outside to get fresh air. Crazy idea eh?
|
|
jordy:
|
are usb devices portable across architectures? can i use a mac usb floppy drive on my pc?
|
|
jordy:
|
anyway, yeah i should go too :)
|
|
anoq:
|
I am flying off too :)
|
|
graydon:
|
ok bye all
|
|
jordy:
|
bye then
|
|
anoq:
|
bye!
|
| | Signoff: anoq (Leaving) |
| | Signoff: jordy (need pizza) |