Older blog entries for async (starting at number 101)

(DRAFT)
some random thoughts on gnome stuff (dunno how realistic it is):


i've been thinking more about the gnome language issue lately. 

two related issues exist here: the needs of the developers working on
the core of gnome (infrastructure), and the needs of the developers
working on applications.

the most flexibility exists with the application developers whose
choices generally affect only themselves.  they should be able to use
the language of their choice and every effort should be made to make
their lives easier (more on that later).

the choices infrastructure developers make affect everyone else, so
more caution is required.  at the same time, requiring infrastructure
developers only use C significantly increases the effort necessary to
write software and keeps them from taking advantage of higher level
language features.

therefore a balance must be struck: take every effort to make both
groups more productive without tying a large, foreign into gnome's
core (note: i don't think anyone is suggesting that mono or java be
used for the core of the platform, but i'm trying to suggest that
there is a middle ground between staying as things are now, and
draggining in mono or java).

given all this, my preference is to improve the object system, create
a convience layer for infrastructure developers, and take steps to
allow application developers to use any language they like.  (this is 
one of havoc's proposed solutions).

identifying some requirements: 

interfaces must be specified with less ambiguity:
	currently interfaces are largely defined by the C header files.  
	using C, most interfaces tend to be under specified, 
	for example:

		foo_bar_baz(foo ** arg0, blah_t * arg1, foo_t * flaz); 

	you don't know what the parameters are doing (in, out, or in/out).
	this creates a problem come time to write bindings for other
	languages, like python where if arg0 is an out parameter, arg1 is 
	an out parameter, you might find 

		( arg0, arg1 ) = foo_bar_baz(flaz)

	since we can pass back multiple values rather than use in/out
	parameters.

	an IDL or some other interface definition language would 
	be better suited.

binary interfaces should be specified: 
	this just means given an interface definition, we should 
	establish and adhere to a known set of calling conventions 
 	so that any language can call into any other language's 
	libraries (one way or another).  (this exists de facto,
	but i believe other issues must be specified).

i'm going to make the assumption that we will be using an object
oriented system one way or another.  i think this is a safe assumption.

it should be easy to subclass existing objects:
	(in order to customize behaviour and create components)

	the current gobject implementation makes it quite painful 
	to derive an object, (or create an object at all), which 
	significantly reduces the probability that people will 
	actually do it.  in many cases functionality which might 
	benefit from being made an object (and possibly reused)
	is instead created in an ad-hoc to speed development.

	under the current regime, only advanced users will do it or be
	able to do it.

objects should provide all pertinent metadata:
	ie function signatures, methods, objects, classes, etc
	(life cycle issues?)

	this helps automatically create bindings whether at runtime
	or compile time

objects should require no special effort to provide a component 
	(in or out of process)
	
	you should get corba (or whatever) bindings for free when you
	create the object (this will aid in allowing other languages
	to use it as well).  currently this is a bit painful because 
	C doesn't allow you to abstract away many of the details.
	
	one should be able to subclass these imported objects in the 
	language they are imported into (with restrictions most likely)  

	
a garbage collector should be provided (as well as a way to get around it).

life cycle/memory management issues should be enumerated and provided
	by metadata so that they can be handled (or at least warned against) 
	

the current system can provide (or already does provide) many of these
without major changes; the biggest barrier is the fact that C makes it
painful to use.  consider the case of using corba in which you have to
initilize your class's virtual method table and what not manually.

the relative lack of use by the community reflects this difficulty.

choosing from mono or java is a divisive issue, and both are in my
opinion poor choices for infrastructure work.  in both cases we tie
ourselves to something we cannot control (and it matters because unlike
C/C++, there are geniune benfits to having input to .net or java
platforms), both require a virtual machine (which don't seem to make
provisions for sharing vm's between multiple applications).  both also
represent a radical departure from what most of us (me) in the
community are used to.


D seems fits (my biases)
well, but currently compiler support is not mature (a gcc front end
for it has only recently appeared).

the compromise would choose would be a precompiler like gob2 which
will allow one to take advantage of the object system easily while
retaining C underneath.  there could in fact be several different
precompilers to suit various tastes.

the major issue is that these mini-languages must be documented and
versioned.

C++ is another possibility, but in my opinion a less desirable one
(with no further justification) .

------------------------

With respect to making developers' lives easier, there are several
issues that must be attacked.  First and foremost we must make sure
that doing the default/normal things are dead easy for a developer.
secondly we must effectively communicate what is available and how to
use it to the developers.  finally, we need a test by which we can
judge our success.

The first two points require us to figure out what developers
actually need to do and what technologies they could use to
accomplish those things.
	here's a laundry list of questions a developer might ask, or
stuff we should provide, etc:

UI:
	GUI interfaces (make them easy to build to the HIG)
	Internationalization (how?/why?/where?)
	Accessibility 
Storage: 
	when do you use the vfs layer?
	when should you not?
	what structured storage is available? when should i use it
IPC/Networking:
	how do i interact with other applications?
	how do i talk dbus or corba?
	how do allow my application to be scripted?

	how do i do DND, how do i do it right?
	how do i use mime types?
	how do i access shared bookmarks?
	how do i use the clipboard	

App Integration: 
	what does it mean for an application to be well-integrated?
	how do use the help system and browser?
	how do i install and remove my application properly?
Media: 
	what media services are available?
	how do i use them?
	how do i play audio? 
	when should i not use them? (less latency, better performance, etc)



most of these things can be done with the platform as is.  but it
tends to be hard.  if we want people to do it (if we want to make it
easier for us to do it), we have to make doing it as easy as possible
and require little or no effort to implement and get right.  for the
most part many of these features remain painful to use as a developer.

we should provide cookie cutter recipies for putting together
applications with minimal effort.  underneath, an experienced
developer should still have access to all the basic components so that
if need be they can customize or create whatever behaviour they need.


--------------------------------

how do we know when we're accomplishing what we've set out to?   
this assessment should be driven by the high level goals: 

	create a coherent and usable desktop for the user 
	create a coherent and usable platform for developers

ultimately, all technological choices should be measured against these
two goals.

these can be further divided substantially; and they must.  the easier
we understand what our goals are (and by "our" that might not mean the
entire "GNOME community", just that group that agrees on them),
the more clearly decisions can be made.

------------------------------------

many of these steps (better documentation, standardization, object
system extensions, etc) are not controversial and can be done (or
begun) today.

--------------------------------------

clearly we should all just relax.
mentifex : your theory doesn't require any debunking. there is nothing to debunk, and the onus is on you to provide evidence for it (if you want to convince others that is).

On hypervisors

grey recently noted an article about cpu virtualization and wondering if it had already been done.

hypervisors have been around for quite sometime. the reason they have been difficult for x86 platforms is that you have to go through some contortions to make it work because the instruction set isn't designed to be virtualizable.

the best available example of one that is is the Power and PPC families. get a copy of mol and have at it (just make it run under linux rather than over, but the concept is the same). that said virtualization doesn't really address ISA/architecture emulation. basically it just does for the cpu what virtual memory does for ram.

17 Mar 2004 (updated 17 Mar 2004 at 06:42 UTC) »
Havoc
or
letting slip the doggies...

regarding this,

my vote would be for a language neutral system with as thin of a runtime as is possible to give you GC and cross-language access (hopefully all running as native code).

gcj would appear to fit into this for the most part; perhaps using a native object system.

also:
currently we have a component system based on CORBA. it's actually very nice to use from python. you can even call python code from C in-process.

one reason this object system never caught on (or at least it never caught on with me) was that you had to go to a lot of extra trouble to expose the interfaces via the object system. (oh and using CORBA in C is awful...10000x worse than g_object's OOP-in-C).

i think whatever the choices made, one property that is important is: any object/interface that a person may create should be automatically available via the component system with as little intervention (by the programmer) as possible.

Akira writes:
Just receive the AI4U book ... I will read it for christmas ... and try to understand why this work is so disparaged.

from scanning the content, i would guess it would be because of the hand-waving, the neologisms, the lack of references to (any) literature, the lack of explanations or justifications, the naive approach to the subject matter, failure to address obvious issues with the approach, ummm, the lack of coherence or focus in the writing, lack of testing, proof by assertion, the wishful thinking, etc, etc.

sure, cog-sci and philosophy are expected to be a bit fluffy, but this is on the level of second grade doodlings of day-dreams of 50 foot tall robots with lasers shooting from its eyes or supercars with rocket launchers (eg. from the fantastic comic WIGU).

P.S. when i grow up i'm going to invent a gun that shoots knives.

hey kids,

i remember someone here who worked on audacity, but don't recall who. i couldn't find a mailing list archive that worked. but i wanted to know:

what's the deal with mac os X support and audio unit support? it currently seems a bit ragged...is it being actively developed? or does it need some love? what needs to be done?

i'd like an audio editor, but i'd rather not spring for bias peak or whatever.

sye:
SOC1B00 Block Diagram. Wonder about the Boot Initialization source Code for the board. And what's this CPLD ? (using CPLD for change to memory map at testing program...?)

what do you wonder about it? cpld stands for complex programmable logic device. it's a chip that you can program to act like some set of individual logic gates.

it looks like they use it for buffering the CF slot and decoding the chip selects on the memory; hence the bit about changing memory maps.

i have drunk the C++ CORBA fruit flavoured drink and it is bitter, yet goes down easier than the C CORBA drink.

the upside is that you don't have to do all the corba stuff in C; the downside is you have to do it in C++.

the proper way to do it of course is to do it in python. unfortunately it is not the appropriate tool for all jobs.

nonetheless, i am glad for the kids that do orbit, orbit-cpp, and pyorbit.

Dear elduderino, 


it's called polyamory. deal.

yours, rob

PS. :D.

PPS. wu-ftpd? i *hope* you were drunk. PPPS. :D

ladypine :

Thanks for the link to the essay by Hofstadter. It is an exceptional piece of satire.

92 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!