goe-developer — Goe developer list

Re: [Goe-dev] Replies....

[Jay M. <ja...@ke...>]

On Wed, 20 Jun 2001 16:34:02 -0700 (MST), <rb...@ce...> said:
>
>  After reviewing your comments and meditating upon it a bit I think that I
>  am going to make a semi-global event list. But I haven't done it yet.
 i commented on this below....

>  The only thing that doesn't happen now (or when I do the global ones) is
>  part D. I'll expand upon that another time.
 that isn't really necessary for testing just yet, and it seems simple enough
to implemented.
  
>  Indeed, one of the thoughts in the back of my mind is that perl is the
>  glue, and it should be so flexable that it should be easy to replace even
>  at the very core. Or even just pieces of it should be replacable.
>  
 that is definately what i was getting at!

>
>  And make it as transparent as possible. If the programmer doesn't need to
>  see the wrapper code they shouldn't have to.
>  
 agreed

>
>  Yes, but at the same time avoiding bloatware. No need to have a full
>  embeded emailer (if we wanted a simple pop up would work, but we could
>  also just call their email client with some defaults for sending it to the
>  right place). And communicating with other programs for chat instead of
>  being too embeded. Or... just making these things optional :)
>  
 exactly, we could do something similar to how browser to mime types (or even
use them) and then have ways of saying 'run this program: ' or 'run this
function:' (although by function it would be more like, call this event -
because we want to be going with the event scheme - its more flexible anyways)
- so that way we have a base to build on (MIME) - a way to extend GOE to bloat
ware (calling events) - but the events may even call other programs anyway
(after formatting input maybe?) - i dunno, but do you get my drift?
 it would be really neat, and would really a whole lot on the event mechanism -
so it would be important to get that solid and stable and in a really good
state.

>  This convinced me of a more-global list. By that I mean that I might make
>  it a class-variable in Goe::Object, which everything inherits from,
>  instead of a true global. You can look at what I already did for the local
>  event version (in Goe::Browser2::Base) and see that I already do a lovely
>  lookup table.
 that seems like a good idea, because that way things that cant get events wont
be able to change it at all. i checked out the lookup table of the current cvs
and i had two questions -
 a) can the callbacks/events be passed arguments? that seems like it would a
good idea. something to design the new one with in mind - the way i see this
being worked around now is the a variable is written to the object's structure
and then the callback grabs it - this is all well until you want that data to
be available to other objects... unless you have them request it from the
object . i dont know what you think is the best way to go about it - either way
will work just about the same (passing to the function is more flexible, but
having the function request from the object follows more OO standards (although
requires functions to be writtten) - i dunno)
 b) it doesnt appear that the callbacks/events can signal passing other events
(either to the same or a different object) - unless they call a function which
would then call the event. i think that this could be useful - but it wouldnot
have to be implemented on it's own. you just write a callback function that can
be passed an object and an event and it hands it that - so that way it
accomplishes the same goal without extra logic/data overhead.

>  Browser2 is to the "browsing" stage, but cannot commit changes or other
>  essential things (like adding methods and such), but it is fun to look at
>  anyway. Feel free to add anything you like, I don't think I'm going to
>  work on it this evening at all anyway. Have fun :)
 i dig completely. i think ill start thinking about the best way to go about
adding stuff.....

some random comments -
 1) you may have noticed i end alot of sentences/paragraphs with "i dunno" -
this is because it is just my rambling brain thinking out loud about possible
ideas. the way i see it the more ideas we generate, whether good or bad, will
only provoke more ideas (or sharpening of current ones) - and the more ideas
floating around the more likely hood that there will be some real rad ones!
 2) something that i do alot when i write programs in spare time and at work is
i write a generlized engine/platform/other_buzzword that has data (normally
formatted in XML.... its a buzzword, yes, but its convient) - that will
instruct the engine on how to operate. i can imagine that making goe along
those lines would be a really interesting exercise/experiment - dream with me
now....
 <ui>
  .... gui objects ....
  <object>
   <type>button</type>
   <event>save_current_file</event>
  </object>
  .... gui objects ....
 </ui>

 <event>
  <id>save_current_file</id>
  <callback>save</callback>
  <arg>#(current_file)</arg>
 </event>

 ------------
  subnote: #(var) is just a short hand/funkd up way of referring to some sort
of variable.... just for quick demo-ing
  notes - is this a good idea? maybe..... the UI description may be a little
over the top - but getting most of the data/description out of the program into
the configuration can only do good for the configurability of the system. the
only thing it can really hurt is developement time and initilization execution
- but it will enable someone to take the goe system and write something ontop
of it more easily....
 just an idea!

Browser2 is cool and this event stuff and other ideas are rad. nice job.
im out like a light

- je'

-- 
Jay McCarthy <ja...@ke...>
aim / aim \ irc
rasarasda / emontapartimejob / feelicks 
www.brunswickrecords.org/~jay/

13~[3357939278861]!
-|[PFDCKHPYVHMJL]|-
}~[897HK8FL3VCY9}~[

Re: [Goe-dev] Replies....

[<rb...@ce...>]

On Mon, 18 Jun 2001, Jay McCarthy wrote:

|  i probably just seemed to load faster because is it less to load and all.
| about the event passing - i havent really looked at the code , just the debug
| messages - and what it appears to me it does is.... in base packages you've
| defined handlers for certain events, these events are called by actions in the
| UI. i think this is really cool because it does a few things -
|  A) simple, ui independant feature base. a gtk ui and a curses ui can call the
| same event just as easily - that will be really cool for having it run in
| different environments
|  B) it also allows some sort of "server" which recieves events from the client
| UI programs - either throughout a local machine or on a network - this would
| all stuff like - file locking and multi site live developement and maybe other
| cool ideas like that
|  C) preferably events will be easy to define, so by just writing a new event
| handler you can add functionality to the program - and since the backend
| handles all events the same GOE could be expanded to the stars and it wouldn't
| care.
|  D) users could redefine which events get called by various UI operations -
| from things like redefining what key Copies to redefining how the open file
| button works - or rather adding a new menu/button item and defining the event
| that gets called
|  I dont know if this is how events work, but if it isnt maybe their current
| implementation can be expanded to fit that idea in somehow.

After reviewing your comments and meditating upon it a bit I think that I
am going to make a semi-global event list. But I haven't done it yet.

The only thing that doesn't happen now (or when I do the global ones) is
part D. I'll expand upon that another time.

|  speaking of playing nice - i think we should design GOE with the ideals of
| expandabilty and user freedom built into everything - i'd like to think of GOE
| more as a developement/organization environment/platform and our perl-ish stuff
| is just one way to implement it and utilize the structure it defines.
| everything should be easy to replace or extend in anyway. although i dont
| aspire to be a webbrowser/mail/news/coffee maker like EMACS - they still have
| the right idea of putting the power in the user with internal programing and
| what not

Indeed, one of the thoughts in the back of my mind is that perl is the
glue, and it should be so flexable that it should be easy to replace even
at the very core. Or even just pieces of it should be replacable.

|  the intelligence i think is the most vital part - we can offer quick 'skeleton
| functions' for interacting with other languages, but it may also be useful to
| make some sort of "wizard"-ish thing that will guide a long a user and either
| let them select a function/object to call/instantiate or browser a library and
| pick something out and also allow to write the function right there - then once
| the user input part is finished you just click generate code and you get some
| quick wrapper code - i think that would be cool and useful in lots of
| situations - and if it were done right it would be easy to add new supported
| languages and what not....

And make it as transparent as possible. If the programmer doesn't need to
see the wrapper code they shouldn't have to.

|  i agree that multilingual dev/imp is a great way to go. i'd like to rephrase
| my thoughts on the OO stuff - what i was really getting at was that there would
| supplied (and a way to write) parsers for any given language which would look
| at the structure of the code and organize it in anyway that the
| user/parser_writer saw fit - examples are inheritance tracking, break down of
| functions, collapsable if/while/for/case blocks (like a lot of windows editors
| have, but i haven't seen a *nix editor with), or maybe a way to build a
| tree/map/graph of all the functions a function calls so that you can visually
| see how a program will interact with the rest of it.
|  i want goe to help those who are lazy or just unorganzied understand their
| programs better and perhaps have a more efficient way to write them with the
| "big picture" in mind - without having to do all that breakup/visualization by
| hand or symbolically.

Yes.

|  i agree, it really gives you a chance to think of everything you could
| possible want done for you when you were organizing a software project. one
| thing i think might be cool as "module" would be associating email addresses
| with objects/files/projects/functions so that an email address of the
| maintainer of a class (stored in some sort of metadata) can be emailed simply
| with right click->email maintainer - maybe even have the program/test run on
| the aspect of the project and send off a bug report formatted in some special
| wayu - i think that would be really neat. and if you wanted to expand on that
| idea, you could have some sort of database/messageboard associated with a
| project so that people/users/developers could comment on parts of the program
| right as they were writing code/debugging it/running it - right from the same
| window - that may be a cool thing to play with

Yes, but at the same time avoiding bloatware. No need to have a full
embeded emailer (if we wanted a simple pop up would work, but we could
also just call their email client with some defaults for sending it to the
right place). And communicating with other programs for chat instead of
being too embeded. Or... just making these things optional :)

|  i definately think it would be important to draw from other people as much as
| possible and allow hooks for others to intergrate GOE into their own projects -
| if not only because it would take to long to reimplement some stuff but also
| because it would be an easy feat if the intergration system was designed in the
| best way possible. (i support fully the vim idea, btw - Vi rucks)

BTW I need to change all the comments that say it is GPL to say it is
licensed like perl (dual). Just a note to self.

|  i can't wait to see it once it's in the cvs repository

Its in there now :)

|  on the event chaining scheme you talked about.....
| A) i agree that is is really good because objects that dont need an event dont
| hear about them - however, does this imply that an event is only sent to one
| object at any level in the heirarchy? obviously it goes to multiple as it
| travels down the chain but can it go to more than one from a given point?
| B) i dont know how this would support the idea that i mentioned earlier about
| events... this is more like a functions says what it wants to look for an those
| events are generated up the chain - and then something else starts the event -
| while this is good it makes it harder to probe and find out what all the events
| that are being handled are, you would have to query every object in the system
| - but maybe thats what we want? you say you dont like a global list, but i
| think maybe a global list would be useful because it would be a single place to
| look, a single place to modify, and you could have it echo the event to any
| situation where it is sent to.
|  the global list could be implemented as some sort of "lookup" table where you
| have on one side the event and on the other side... events that it triggers and
| functions that should get called when the event happens, ie....
|  open_button_push -> file selection dialog() , new code editor()
|  save -> write_to_fs() , update_cvs(), structure_changed!
|  structure_changed -> reparse_project()
|  make sense? do you think that that is unneccessary and able to be down with
| the event scheme you have currently?

This convinced me of a more-global list. By that I mean that I might make
it a class-variable in Goe::Object, which everything inherits from,
instead of a true global. You can look at what I already did for the local
event version (in Goe::Browser2::Base) and see that I already do a lovely
lookup table.

Browser2 is to the "browsing" stage, but cannot commit changes or other
essential things (like adding methods and such), but it is fun to look at
anyway. Feel free to add anything you like, I don't think I'm going to
work on it this evening at all anyway. Have fun :)

--Brock

[Goe-dev] Replies....

[Jay M. <ja...@ke...>]

i've had to write these ideas a couple times because my email client ate the
last sent - so maybe you talk about them, but either way i'll ust get them all
down, hopefully it is a readable format....

> | i checked out the new browser, looks more organized and seemed to load faster.
> | i didnt get much of an opportunity to inspect it deeply but ill have a lot of
> | time this weekend to dig into the code and play with it.
> 
> Excellent. It probably didn't really load faster, its just an illusion. I
> am still trying to think out a clean organization for it, and so far I
> like how its going. The event passing mechanism is the part I've been
> contemplating the most lately, I think what I have will work.
 i probably just seemed to load faster because is it less to load and all.
about the event passing - i havent really looked at the code , just the debug
messages - and what it appears to me it does is.... in base packages you've
defined handlers for certain events, these events are called by actions in the
UI. i think this is really cool because it does a few things -
 A) simple, ui independant feature base. a gtk ui and a curses ui can call the
same event just as easily - that will be really cool for having it run in
different environments
 B) it also allows some sort of "server" which recieves events from the client
UI programs - either throughout a local machine or on a network - this would
all stuff like - file locking and multi site live developement and maybe other
cool ideas like that
 C) preferably events will be easy to define, so by just writing a new event
handler you can add functionality to the program - and since the backend
handles all events the same GOE could be expanded to the stars and it wouldn't
care.
 D) users could redefine which events get called by various UI operations -
from things like redefining what key Copies to redefining how the open file
button works - or rather adding a new menu/button item and defining the event
that gets called
 I dont know if this is how events work, but if it isnt maybe their current
implementation can be expanded to fit that idea in somehow.

> I didn't change anything, really. Merely uploaded the html for display at
> goe.sf.net - it wasn't there at all before - and set up the CVS.
 alright, thats what i figured - i have a cvs repository on my machine now but
i havent really dug into any code yet. i'd rather get a feel for the current
source and solidify some ideas that i have - i like have a solid base of ideas
before starting to write spagetti code.

> Yes, I'm getting increasingly agitated at the cable company. The only
> reason I'm putting up with it is that the apartment complex is going to
> pay for it, so in the end its free for me.
 supposedly ill be getting cable soo too - that'll be sooo much better than a
modem!

> | 13~[7069765033060]!
> | -|[UMDUOOUPKVQVT]|-
> | }~[7P3M0669T7360}~[
> 
> What, dare I ask, does this mean?
 this is just my sig which is a perl script which generates some randoms
letters and numbers and displays them in an interesting way - i think it looks
cool. it doesnt really mean anything, aside from the fact that the 13 is always
there and there are 13 numbers, 13 letters, and a mixture of 13 of them -
because 13 is soo lucky. i used to have a quote as a sig but i got tired of it.

> 
> There are quite a few companies that use it in-house, but I can't think of
> any end user commercial programs at all. Mostly it is used for prototyping
> a project, and once the concept is sold they move to a different platform.
 it seems like it would be really good for fast prototyping of gui
applications, i dont know but it gives me that impression.
 
> That quote was in quite a bit of context, but yes in ways they are proud
> of being closed. Or rather some of them are. The more extreme perspective
> among them is that squeak is the perfect world and tainting it is bad. But
> there are others that share my sentiment, that if they ever want people to
> use it they'll have to play nice with others.
 speaking of playing nice - i think we should design GOE with the ideals of
expandabilty and user freedom built into everything - i'd like to think of GOE
more as a developement/organization environment/platform and our perl-ish stuff
is just one way to implement it and utilize the structure it defines.
everything should be easy to replace or extend in anyway. although i dont
aspire to be a webbrowser/mail/news/coffee maker like EMACS - they still have
the right idea of putting the power in the user with internal programing and
what not
 
> I think that when browsing with the package tree being primary the
> inheritence tree will be mostly for adding / removing parent classes. It
> would also be able to browse the parent packages, on a double click or a
> right-click menu option for instance.
 it may also be good to be able to have fast access to method lists and
internal data of a parent class that you may need to get information on. that
makes a lot of sense, the previous thing i said would be confusing for a user
and also rather pointless....

> | > Hey, did you look at / think about the Inline thing?
> | ......
> | developement and integration - is that where you want to go?
> 
> XS is terrible, you could almost think of this as an intelligent
> replacement for XS in some situations. But you're right, the more
> important thing I was thinking about is in regards to Goe.
 the intelligence i think is the most vital part - we can offer quick 'skeleton
functions' for interacting with other languages, but it may also be useful to
make some sort of "wizard"-ish thing that will guide a long a user and either
let them select a function/object to call/instantiate or browser a library and
pick something out and also allow to write the function right there - then once
the user input part is finished you just click generate code and you get some
quick wrapper code - i think that would be cool and useful in lots of
situations - and if it were done right it would be easy to add new supported
languages and what not....
 
> The main thing that I am thinking is along the multilingual development
> and integration path. The only thing I see differently than you write
> above is about non-OO languages. The way I'm trying to write Goe is along
> with Perl's More Than One Way approach. There is nothing enforcing the
> object orientedness that I'm currently using, I just choose to write the
> system that way. Just parsing those languages down to the file / function
> level would be good enough, I think. Just like in perl I can pretend,
> simply by calling functions without using magical -> sytax, that I am not
> Object Oriented at all (though I think I'm really pretending the other way
> around). Make sense?
 i agree that multilingual dev/imp is a great way to go. i'd like to rephrase
my thoughts on the OO stuff - what i was really getting at was that there would
supplied (and a way to write) parsers for any given language which would look
at the structure of the code and organize it in anyway that the
user/parser_writer saw fit - examples are inheritance tracking, break down of
functions, collapsable if/while/for/case blocks (like a lot of windows editors
have, but i haven't seen a *nix editor with), or maybe a way to build a
tree/map/graph of all the functions a function calls so that you can visually
see how a program will interact with the rest of it.
 i want goe to help those who are lazy or just unorganzied understand their
programs better and perhaps have a more efficient way to write them with the
"big picture" in mind - without having to do all that breakup/visualization by
hand or symbolically.

> | other things that would be interesting....
> 
> See, this project is just a generator of ideas! My theory is that since we
> are using the project to work on itself a lot of needs, wants, and
> problems will become obvious to us while we build it all up.
 i agree, it really gives you a chance to think of everything you could
possible want done for you when you were organizing a software project. one
thing i think might be cool as "module" would be associating email addresses
with objects/files/projects/functions so that an email address of the
maintainer of a class (stored in some sort of metadata) can be emailed simply
with right click->email maintainer - maybe even have the program/test run on
the aspect of the project and send off a bug report formatted in some special
wayu - i think that would be really neat. and if you wanted to expand on that
idea, you could have some sort of database/messageboard associated with a
project so that people/users/developers could comment on parts of the program
right as they were writing code/debugging it/running it - right from the same
window - that may be a cool thing to play with

> One thing that I thought of while reading this stuff is how well Goe will
> interface with other programs / systems. I don't want to be sucked in to
> the same trap that so many of the SmallTalk people have. And I want to use
> vim (embedded, preferably) as a plug-in editor :)
 i definately think it would be important to draw from other people as much as
possible and allow hooks for others to intergrate GOE into their own projects -
if not only because it would take to long to reimplement some stuff but also
because it would be an easy feat if the intergration system was designed in the
best way possible. (i support fully the vim idea, btw - Vi rucks)
 
> I talk a bit about my vision for Goe in my webpage. The thing is that the
> project can shoot off in so many different directions. I want it to be a
> very pleasant programming environment, meaning well organized and easy to
> use and things like that. And I think that is where I'll start.
> 
> I mention GUI wrappers. I want that so that I am liberated from having to
> use one GUI kit (gtk, win32, tk, qt,...). Inline will liberate me from
> having to use one language. The very customizable browser, along with any
> other tools we add, will liberate me from having to use inneficient
> programming environments. So... I guess overall I seek liberation. Perl
> itself has been a great starting point. Hm... liberation and cleanness.

 organization, freedom, and cleannes are also my key concerns - i had a big
long thing about this in the first version of the mail but it has degraded and
the ideas dispersed in previous paragraphs. but yes - i agree.

On Mon, 18 Jun 2001 11:32:04 -0700 (MST), <rb...@ce...> said:

 >  I couldn't find a floppy disk this morning, so my update won't come till
>  tomorrow. The new browser is almost complete, and I might even have it
>  done by tomorrow. The framework I've set up is allready being effective,
>  each piece I add is working right away and is easier to code.
 i can't wait to see it once it's in the cvs repository

 on the event chaining scheme you talked about.....
A) i agree that is is really good because objects that dont need an event dont
hear about them - however, does this imply that an event is only sent to one
object at any level in the heirarchy? obviously it goes to multiple as it
travels down the chain but can it go to more than one from a given point?
B) i dont know how this would support the idea that i mentioned earlier about
events... this is more like a functions says what it wants to look for an those
events are generated up the chain - and then something else starts the event -
while this is good it makes it harder to probe and find out what all the events
that are being handled are, you would have to query every object in the system
- but maybe thats what we want? you say you dont like a global list, but i
think maybe a global list would be useful because it would be a single place to
look, a single place to modify, and you could have it echo the event to any
situation where it is sent to.
 the global list could be implemented as some sort of "lookup" table where you
have on one side the event and on the other side... events that it triggers and
functions that should get called when the event happens, ie....
 open_button_push -> file selection dialog() , new code editor()
 save -> write_to_fs() , update_cvs(), structure_changed!
 structure_changed -> reparse_project()
 make sense? do you think that that is unneccessary and able to be down with
the event scheme you have currently? 

 i'll have to look at the code and experiment with how it can be played with -
i dont know the specifics so ill have to check it out.
 hopefully this mail will actually get sent.!

 out, je'
-- 
Jay McCarthy <ja...@ke...>
aim / aim \ irc
rasarasda / emontapartimejob / feelicks 
www.brunswickrecords.org/~jay/

13~[8354774074444]!
-|[RFYDSCPJPZNUM]|-
}~[Z74N74FM4J348}~[

[Goe-dev] mail problem

[Jay M. <ja...@c-...>]

i just wrote a many page insightful reply to your mails but my mail client ate
it in a strange database error and i dont have the time to rewrite it now... so
i'll do it when i have more time. i'm listening though and i have ideas.
and im very angry right now.... damn database without rollback transactions....

je'

-- 

Jay McCarthy
CIS Technical Services

[Goe-dev] Browser2 and events

[<rb...@ce...>]

I couldn't find a floppy disk this morning, so my update won't come till
tomorrow. The new browser is almost complete, and I might even have it
done by tomorrow. The framework I've set up is allready being effective,
each piece I add is working right away and is easier to code.

I made a comment in the souce code, but thought I could ask you about
something too. I am trying out an event handler scheme. Assuming you have
a fixed point font, lets demonstrate.

+--Browser
  |
  +--Panes
  | |
  | +--PackageTree
  | |
  | +--MethodList
  |
  +--Editor
    |
    +--Code


So when instantiated, MethodList runs

$self->{owner}->add_event(
  'curPkg changed' => sub{$self->refresh} );

So that its owner (Panes) will be sure to tell it if curPkg (the package
currently being viewed) changes. When someone clicks on a new package in
the PackageTree, PackageTree does this

$self->do_event('curPkg changed');

The event is then passed upwards (through 'owner'). Panes gets it, then
runs the code that has been registered in its event list by MethodList,
who itself runs 'refresh'.

So far the event scheme is working well, with the events being localized
(no objects recieve the event that don't need to, save on execution time)
and have gotten to those who need them. The problem I'm contemplating now
is when packages on further branches of code want to use events. I'm
fairly sure the method I'm doing will work, which is to force any chains
of events that go down the tree to be explicit.

For instance, when a new method is clicked in MethodList a 'curMethod
changed' event is issued. In order for the Code package to know of the
event, and thus change what method is being displayed, its owner, Editor,
must register the event with Browser, and then issue its own event. In
order to use this backwards-flowing chain eficciently I created the
do_local_event method (in the Browser::Base package, along with the other
event stuff) so events would then not escape upwards without reason to.

How does this scheme sound to you? The only alternative I thought of was a
global event list, but I don't like global things. On the other hand, a
global event list might be simpler. The other thing to consider is the
order in which events get called back. Right now packages that are closer
to where the event takes place know about it before ones that are far
away, whereas in the Global List it would be very first-declaired
first-served.

--Brock

[Goe-dev] Re: GOE

[<rb...@ce...>]

On Thu, 14 Jun 2001, Jay McCarthy wrote:

|
| On Wed, 13 Jun 2001 13:31:11 -0700 (MST), rb...@ce... said:
| > ...
|  the closeness of squeak is what i was thinking was probably the reason for it.
| i was talking to one of my friends about me experimenting with smalltalk and he
| said to me "what's the point of smalltalk? it's just one of those languages
| people waste their time with and never write anything in". whether this is true
| or not i couldn't verify but it wouldnt surprise me if people just used it for
| research.

There are quite a few companies that use it in-house, but I can't think of
any end user commercial programs at all. Mostly it is used for prototyping
a project, and once the concept is sold they move to a different platform.

|  the squeak people seem proud of the closeness, this is gather from the quote
| on the page "You start a fork every time you save an image", maybe they see
| that as a good thing.... i dunno.
|  i have squeakland open in another window, i'll be looking at it.

That quote was in quite a bit of context, but yes in ways they are proud
of being closed. Or rather some of them are. The more extreme perspective
among them is that squeak is the perfect world and tainting it is bad. But
there are others that share my sentiment, that if they ever want people to
use it they'll have to play nice with others.

| >  In smalltalk the tree-like pane is an object inheritance heiarchy. In Goe
| >  it is just a package heiarchy, not indicating what each package (Object)
| >  inherits from, but only some package structure. I think that both
| >  Inheritance heiarchy views and Package heiarchy views are important, but
| >  my philosophy is that the Package Tree is more important for most
| >  development. In the browser I'm making now (the re-write) the view will be
| >  configurable so you can see any panes you want. By default I think it will
| >  first have the Package Tree, then the Inheritance Tree (listing all the
| >  things that the current Package inherits from), and then the method list.
| >  The method "group" is just a way of organizing methods, and isn't
| >  mandatory at all. You would use this to further organize, seperating I/O
| >  methods from member access methods, for instance.
| >
|  good explanation, i get it now. are the inherited from packages displayed for
| only information ? when you select one will you be looking at that package's
| main view and thus have "climbed up" the hierarchy?

I think that when browsing with the package tree being primary the
inheritence tree will be mostly for adding / removing parent classes. It
would also be able to browse the parent packages, on a double click or a
right-click menu option for instance.

| i like the idea that you
| can customize the views and create groups of related functions. configurability
| is key in every aspect of the system - this is why things like X and emacs
| succeed, because every aspect can be change by someone (relatively easily i
| mean, obviously anyone can change the source but most people prefer to change
| the "data" that describes how the system works).
|  another configurable aspect that would be useful to have would be different
| ways to export your packages. as one package... broken up by sub object, or
| whatever.

Yes, I agree. I hope that not only will the system itself behave in that
way, but also will lend itself to easily create programs that do so as
well.

| >  Hey, did you look at / think about the Inline thing?
| ya, i grabbed the module and some of the supported languages and checked out
| the C cookbook. its a good idea but i failed to think of practical applications
| of it. the only one that occurred off the top of my head would be quick
| wrappers around C libraries but, i have a feeling that would be rather slow and
| it would make more sense to just do an XS (which i have never done... so i dont
| know how hard that is). so, as it stands on its own i dont see much useful
| about Inline - however, in relation to GOE i think that it can be really
| useful. Basically, GOE could have language 'modes' and be able to produce
| code/comments/object heirarchies for an of the supported languages - and this
| could be done in a couple ways....
|  for native object oriented languages (c++, perl, python) there are parsers
| that can pull out information about the objects/class, and such.
|  for languages that can simulate object oriented languages (c, c++ was
| originally a C++ to C translator as you may know) - there will be either: *
| embedded comments that describe the object and how it relates to the rest (and
| this will be parsed) - or possible something based on files or function names.
|  basically. Inline could compliment this by being able to execute the code
| inside of the program, rather than having to resort to outside programs.... or
| GOE could generate "on-the-fly" code to have your perl programs interface other
| C/Python/etc programs/functions that are within the GOE universe/project.
|  this would be turning GOE into a full environment for multi-language
| developement and integration - is that where you want to go?

XS is terrible, you could almost think of this as an intelligent
replacement for XS in some situations. But you're right, the more
important thing I was thinking about is in regards to Goe.

The main thing that I am thinking is along the multilingual development
and integration path. The only thing I see differently than you write
above is about non-OO languages. The way I'm trying to write Goe is along
with Perl's More Than One Way approach. There is nothing enforcing the
object orientedness that I'm currently using, I just choose to write the
system that way. Just parsing those languages down to the file / function
level would be good enough, I think. Just like in perl I can pretend,
simply by calling functions without using magical -> sytax, that I am not
Object Oriented at all (though I think I'm really pretending the other way
around). Make sense?

| -----
| currently as i understand it GOE is just the browser but hopes to be a full gui
| wrapper/editor/source broweser/project organizer.
| too many projects are just going for "IDE" - either for Gtk or Tk. i
| persronally have never worked on a perl project with a GUI and i have been
| working with perl for years. it's not something im interested in. what I AM
| interested in is an environment to better organize my projects. this is what
| was first attractive about GOE, i think it's a great idea to seperate each
| package and be able to address each method individually - that is key.
| so based off that i envision the class browser to just be able to be an
| instance of the browser of a project with many different packages making it
| up....

I'm not sure exactly what you mean in the last sentence. But... yeah :)

| other things that would be interesting....
|  running the program - simply opening up a terminal and running it
|  debugging - opening up a graphical debugger or a console (btw, have you looked
| at Devel::ptkdb - a perl tk debugger, really cool)
|  test running - write tests that you can run against a program/package to test
| that it is working as it should
|  cvs update/commit/add/remove frontends - nothing too complicated
|
| obviously it would be a good idea to be able to have a user specify
| modules/packages/plugins that they will use which will add entries to the
| menus, all the above things may be examples.
|

See, this project is just a generator of ideas! My theory is that since we
are using the project to work on itself a lot of needs, wants, and
problems will become obvious to us while we build it all up.

| i dont know if this is the direction you want to go. what is your "vision" for
| GOE?

One thing that I thought of while reading this stuff is how well Goe will
interface with other programs / systems. I don't want to be sucked in to
the same trap that so many of the SmallTalk people have. And I want to use
vim (embedded, preferably) as a plug-in editor :)

I talk a bit about my vision for Goe in my webpage. The thing is that the
project can shoot off in so many different directions. I want it to be a
very pleasant programming environment, meaning well organized and easy to
use and things like that. And I think that is where I'll start.

I mention GUI wrappers. I want that so that I am liberated from having to
use one GUI kit (gtk, win32, tk, qt,...). Inline will liberate me from
having to use one language. The very customizable browser, along with any
other tools we add, will liberate me from having to use inneficient
programming environments. So... I guess overall I seek liberation. Perl
itself has been a great starting point. Hm... liberation and cleanness.

--Brock

[Goe-dev] general

[<rb...@ce...>]

On Fri, 15 Jun 2001, Jay McCarthy wrote:

| I got the new tar ball from the site, and i got myself added to the
| goe-developer mailinglist and i got myself a sourceforge account.
| the name of the sourceforge account is 'feelicks'
| i checked out the new browser, looks more organized and seemed to load faster.
| i didnt get much of an opportunity to inspect it deeply but ill have a lot of
| time this weekend to dig into the code and play with it.

Excellent. It probably didn't really load faster, its just an illusion. I
am still trying to think out a clean organization for it, and so far I
like how its going. The event passing mechanism is the part I've been
contemplating the most lately, I think what I have will work.

| what did you change about the site? i didnt see a change on goe.sourceforge.net
| or deathonastick.org/projects/perl/goe/html
| or did you just mean the sourceforge project?

I didn't change anything, really. Merely uploaded the html for display at
goe.sf.net - it wasn't there at all before - and set up the CVS.

| i'll be getting a feel for the code in the project,
| i'd like to discuss our ideas any time it's convenient for you, i'll be around
| most of the time to respond to emails. that must be rough not having a
| connection at home. to think, i complain about having a slow connection at
| home, i cant even imagine not having one.

Yes, I'm getting increasingly agitated at the cable company. The only
reason I'm putting up with it is that the apartment complex is going to
pay for it, so in the end its free for me.

| 13~[7069765033060]!
| -|[UMDUOOUPKVQVT]|-
| }~[7P3M0669T7360}~[

What, dare I ask, does this mean?

--Brock

[Goe-dev] test

[<rb...@ce...>]

Testing the new mailing list

--Brock