embedlets-developer Mailing List for Outpost Embedlet Container (Page 19)
Status: Alpha
Brought to you by:
tkosan
Menu
▾
▴
embedlets-developer — Outpost Embedlet container developer list
You can subscribe to this list here.
| 2003 |
Jan
(135) |
Feb
(402) |
Mar
(162) |
Apr
(22) |
May
(13) |
Jun
(67) |
Jul
(59) |
Aug
(27) |
Sep
(1) |
Oct
(28) |
Nov
(81) |
Dec
(16) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(2) |
Feb
(21) |
Mar
(6) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
(13) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2006 |
Jan
(4) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Nicola K. B. <nic...@ap...> - 2003-03-08 08:41:11
|
Andrzej Jan Taramina wrote, On 07/03/2003 22.36: > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] ... >>As soon as I can get a good tagged source tree I'll start creating test >>cases built on top of Cork, with some device access... but I want to know what >>changes (and how) before I start having to replace my source tree on every >>update. > > No problem....it won't be too long. > > How about this for a temporary solution......I'll post full > source/distribution trees to CVS sooner (ie. this weekend), rather than > later. Good :-) In OS CVS is the real scratchpad for all, like the mailing list is the discussion place. > However, I think to keep a handle on things and to minimize the impact on > other people's work, we should allocate some responsibilities as to who > "owns" certain pieces. The part I'm most worried about is churn in the > Embedlet Core Interfaces and Outpost Core Services, which would have > widespread impact if the changes are not managed. Testcases and discussions. You will see that people naturally get to work on certain parts, and decide that informally on the ML. It works well, and there is no "formal" need of assigning things, that maybe don't get followed for instant lack of time. For the "commmon" parts, testcases runing regularly via a cron job are the only real way of keeping things stable, also for when developers leave the group for any reason. I'd be happy to add this project to the ones run by Gump http://jakarta.apache.org/gump/ > It seems we have already stratified to a great degree, with you on JAPL, Ted > taking the Graphical Wiring (hey Ted....the current Outpost RI has enough > dynamic capability that you can already start thinking/working on this!), me > on Core (embedlet spec and core Outpost RI services), Chris is very > interested in the Persistence Service and Gregg is interested in doing a Mesh > inter-system communications service. If we keep this responsibility > structure for the moment it will allow us to go forward quickly with a > minimum of disruptive impact. > > Does this make sense? Hmmm, responsibility is of everybody to the same degree. If we keep things too separated, knowledge gets shared less... and the project starts depending too much on a single person. Yes, there are concern areas, and parts of code that some prefer, but as you have seen yourself, a natural layering has already occurred ;-) -- Nicola Ken Barozzi nic...@ap... - verba volant, scripta manent - (discussions get forgotten, just code remains) --------------------------------------------------------------------- |
|
From: Ted K. <tk...@ya...> - 2003-03-08 05:12:48
|
Sheesh! You guys were really flying fast and furious there with the posts for about an hour or so! And wouldn't you know I had just bumped into a girl I use to know in high school just before it started and I was chatting with her (and I almost *never* chat with anyone but for her I made an exception ;-) Your posts kept popping up over top of my chat session and messing up my concentration! <private list idea> Anyway, as for the private list idea, after spending a significant amount of time combing through the Apache developer lists in preparation for starting up the Embedlets project I discovered that it appears to be normal practice for *almost all* development traffic to be placed on the open developer's list for the whole world to see. Some of Stefano Mazzocchi's candid posts were especially illuminating and to me they illustrated nicely that open source development can get rough at times but that this is normal. And believe me, our development traffic has been extremely civil when compared to some of the traffic that other well known projects have generated... <developer credit> Actually, I thought that we had already had the beginnings of a discussion on the developer credit topic when the licensing issue first came up. The conclusion was that ultimately we would need to create an Embedlets legal entity to hold the Embedlets license but until that time one of us would need to put our name on the source code in order to make the license stick. Since Andrzej took it upon himself to sling the seed code base, he said that he would take responsibility for the license for now until the legal entity was set up. Perhaps some of this discussion went on off list which is yet another good reason to have as much development traffic go through the main development list as possible I guess... Anyway, Andrzej also said that the code he was posting was for discussion purposes only and it was more like a very detailed illustration of what Embedlets and an Embedlet container might look like rather than an official code base. This was probably also a good reason for not officially placing the code under version control because none of these issues had been worked out yet. In fact, perhaps we should hold off on officially placing the code into the CVS until we create the Embedlets legal entity and get the license and credits arranged the way we want them? From my perspective, I would not mind having my name listed on the architecture document as an idea contributor but I do not think my name should go on any of the core Embedlets or Outpost code unless I actually end up contributing some code or critical thinking to these pieces at some point in time. The Embedlets Container and code base is definitely Gregg's, Chris's and Andrzej's baby and I would imagine that their names would be the primary ones to appear in this code. Actually, I have been studying the code this week in order to finally figure out what the heck you three have been cooking up over the past month or so. It is slowly started to sink in though... I am just happy to be helping out with this effort and I feel privlidged to be able to learn all of these cutting-edge technologies from people who have had years of experience in this area. And of course I hope to make a significant code contribution with the Wiring Tool too just as Brill will be making one with the JAPL Cork implementation. So, does anyone know how we about creating an Embedlets legal entity? Ted __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ |
|
From: Christopher S. <cs...@oo...> - 2003-03-08 01:18:58
|
Andrzej,
On the class hierachy:
Is there a reason you have not used interfaces as the starting point for the
abstract classes? This requires an extra class(interface) but it provides a
huge amount of flexibility if we need to substitute versions (full/lite) or
platform specific implementations later.
As you know it would be a simple level to add at the top:
iComponent
^
:__ Component
^
|____ Embedlet
Chris
> Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE]
> _______________________________________________
>
> Brill says:
>
> > I think you'll start getting feedback when we start to actually try to
> > implement test cases... I have the same problem with Cork,
> where I don't get
> > much feedback, so I don't know if the system is working for anyone ;)
>
> I hear ya....bit of a chicken and egg, but with the stuff I have done, we
> have the spec (embedlets), the container RI (outpost) and the sample app
> (outhouse), so there is a lot to look at and review. The design of the
> embedlet API's is especially critical.
>
> > As soon as I can get a good tagged source tree I'll start creating test
> > cases built on top of Cork, with some device access... but I
> want to know what
> > changes (and how) before I start having to replace my source
> tree on every
> > update.
>
> No problem....it won't be too long.
>
> How about this for a temporary solution......I'll post full
> source/distribution trees to CVS sooner (ie. this weekend), rather than
> later.
>
> However, I think to keep a handle on things and to minimize the impact on
> other people's work, we should allocate some responsibilities as to who
> "owns" certain pieces. The part I'm most worried about is churn in the
> Embedlet Core Interfaces and Outpost Core Services, which would have
> widespread impact if the changes are not managed.
>
> It seems we have already stratified to a great degree, with you
> on JAPL, Ted
> taking the Graphical Wiring (hey Ted....the current Outpost RI has enough
> dynamic capability that you can already start thinking/working on
> this!), me
> on Core (embedlet spec and core Outpost RI services), Chris is very
> interested in the Persistence Service and Gregg is interested in
> doing a Mesh
> inter-system communications service. If we keep this responsibility
> structure for the moment it will allow us to go forward quickly with a
> minimum of disruptive impact.
>
> Does this make sense?
>
> > be careful with Jalopy.. I integrated it into the cork build a
> little while
> > ago, but found it caused more problems with my source tree than
> it was worth,
> > so instead I have it set up so I can manually format a
> particular source file
> > when I'm working on it. If your going to set up it, I suggest
> you only do it
> > with an automated CVS commit, and only just before the commit
> takes place (and
> > only the files that have changed!) otherwise you get Jalopy
> resetting all the
> > files changed or not, and CVS thinks they have changed.
>
> I was thinking about those issues....and will see what I can do
> about them.
>
> > Ok, lets check it in, tag it, and we can branch it later if we
> need to.... I
> > also suggest a separate branch (or module) for my japl
> integration, as I don't
> > know yet just from looking what I will have to do.
>
> Make JAPL a separate module. Since I've been keeping everything
> decoupled
> and separated, I will create three modules for my source trees,
> one each for
> Embedlets, Outpost and Outhouse.
>
> > heh... Yah, the age old problem... I find it easier to do brief
> > documentation, get something working, and go back and document,
> then do the
> > next chunk... the long and short is that no matter how much you
> pre-design
> > something, you can never actually know its right until you get
> down to brass
> > tacks, and make it work.
>
> I agree...which is why I went on the spree bouncing back and
> forth between
> the spec (embedlets) the RI (outpost) and a test app (outhouse)
> since it was
> faster to do this with only one person. But now there is a lot
> of "meat" in
> place....and so it needs some peer review. It's not like the
> code base is
> just interfaces, since there is a lot of implementation stuff behind it
> already.
>
>
> Andrzej Jan Taramina
> Chaeron Corporation: Enterprise System Solutions
> http://www.chaeron.com
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Etnus, makers of TotalView,
> The debugger
> for complex code. Debugging C/C++ programs can leave you feeling lost and
> disoriented. TotalView can help you find your way. Available on
> major UNIX
> and Linux platforms. Try it free. www.etnus.com
> _______________________________________________
> Embedlets-developer mailing list
> Emb...@li...
> https://lists.sourceforge.net/lists/listinfo/embedlets-developer
>
|
|
From: Christopher S. <cs...@oo...> - 2003-03-08 00:15:31
|
> > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > _______________________________________________ > > Chris observes: > > > That all makes sense for events that can afford to fail (logs, user > > interaction etc.) For those that cannot there needs to be a queue-bypass > > path that can complete in a given amount of time. Fortunately the > > synchronous event stack depth would be deterministic since a given event > > would have a known path based on the consumers that are registered. The > > last event in the path may be asynchronous as in a logging event, user > > notification. This mix and match of sync/async events is central to real > > time operation with external client processes. > > I absolutely agree....and Synchronous event sending is now > implemented. The > next version to go up (this weekend) will have that in place. > > > But you would use an interrupt driven event to notify critical embedlets > > that something needs to be done NOW! This kind of event could occur on > > sub-millisecond to an hour or more interval. The important thing is that > > there is a mechanism to define the mission critical event and guarantee > > its immediate delivery. This way the developer does not have to > 'punt' too > > early in the game because Embedlets cannot deliver! > > Yup....but I see the interrupt-generation and initial receipt as being a > device driver issue (JAPL?) which will then send a Synchronous > event to an > Embedlet to do something useful with the interrupt notification. > > I'll give some thought to a way of grabbing a global async thread lock so > that all other threads get blocked while the synchronous event is being > propagated, for the ultra-critical events. Otherwise, even a synchronous > event propagation can be pre-empted by an async thread execution. What is the problem with bypassing the container involvment and relying on the RTOS thread priortization to manage the thread switch? That is what it is there for! This would involve 1. The sendEvent(Event) method being thread-safe for synchronous events 2. Events would store their own consumer collection (or an event per consumer) 3. The sendEvent(Event) just turns around and invokes the 4. Async events would signal the background queuing thread to wake up and do it's thing. > > > This makes the most sense in core Embedlet communication. This makes the > > 'wires' a solid connection between produce and consumers and ensures > > prompt processing of events. Async events will be very important as well > > to off load communication between more loosely coupled > processes to lower > > priority services. > > Yup! And we now have both. > > > We should probably put together a 'When to use Sync/Async > events' document > > based on this discussion thread. > > For sure....this would be very useful. > Andrzej Jan Taramina > Chaeron Corporation: Enterprise System Solutions > http://www.chaeron.com > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Etnus, makers of TotalView, > The debugger > for complex code. Debugging C/C++ programs can leave you feeling lost and > disoriented. TotalView can help you find your way. Available on > major UNIX > and Linux platforms. Try it free. www.etnus.com > _______________________________________________ > Embedlets-developer mailing list > Emb...@li... > https://lists.sourceforge.net/lists/listinfo/embedlets-developer > |
|
From: Christopher S. <cs...@oo...> - 2003-03-08 00:11:02
|
> Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > _______________________________________________ > > It was bugging me, so I did some investigation, and found that > one particular > operation was killing the TINI performance, and that was > accessing various > component property values during the event propagation process. > I refactored > that so that Components (eg. Embedlets) cache their static values > in instance > variables (things like the unique ID, description, version, etc.) > and also > refactored how Lifecycle state was get/set in a similar manner. > I hate... no I actually love, to harp on this. This is the issue that we went round and round on not so long ago. As I pointed out: 1. Performance will suffer due to the variable lookup being in-line with mission critical code. 2. Programmers will be reluctant to make every variable access an indirect call to a context object. 3. The context Hastable becomes a thread contention item that has to be synchronized, bottle-necking multithreaded access (I did not point this out but it is a fact). Reversing the roles so that the Context is only there to provide initialization properties and to transform/transport Embedlet properties only when needed, is the way to go, IMNSHO. I am very impressed with the xRAD development process that you are demonstrating. Within a couple of days, a critical issue was surfaced, diagnosed, addressed and fixed! My hat off to you! > Here were the results, comparing async and sync event propagation > (all values > in events/second) before and after the refactorings: > > PLATFORM ASYNC SYNC (Recycled) SYNC (Non-Recycled) > > TINI (before): 8 13 > 143 > TINI (after): 12 71 > 133 > > As you can see, the Async speed improved by 50%. The Sync speed using > recycled event instances (so only one is ever created) was > markedly improved > by the refactoring. The Sync (Non-recycled) slowed down a trifle > due to some > other refactoring that I put in place to improve the Embedlet > spec interfaces > a bit, but the net loss in speed was only about 7% (and those structural > refactorings were necessary). > > I figure the SYNC (Non-Recycled) is running about as fast as the > poor TINI > can go, and though there might be some minor tweaking that could possibly > help a bit, that's about all she wrote. With the new > refactorings, the SYNC > (Recycled) path is probably approaching optimum as well. > > However, the Async is still quite disappointing. Sure it's using > threads and > thread context switches, but I think it should be a bit closer to > the SYNC > (Recycled) performance. My gut feel is that this can probably be > improved a > fair bit by optimizing the queue structures (away from generic > Vectors and > Hashtables to more customized versions that are specifically tuned to the > access patterns that async event propagation produces). So there > is still > lots of room there I think. > > > > > > Andrzej Jan Taramina > Chaeron Corporation: Enterprise System Solutions > http://www.chaeron.com > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Etnus, makers of TotalView, > The debugger > for complex code. Debugging C/C++ programs can leave you feeling lost and > disoriented. TotalView can help you find your way. Available on > major UNIX > and Linux platforms. Try it free. www.etnus.com > _______________________________________________ > Embedlets-developer mailing list > Emb...@li... > https://lists.sourceforge.net/lists/listinfo/embedlets-developer > |
|
From: Andrzej J. T. <an...@ch...> - 2003-03-07 21:36:51
|
Brill says: > I think you'll start getting feedback when we start to actually try to > implement test cases... I have the same problem with Cork, where I don't get > much feedback, so I don't know if the system is working for anyone ;) I hear ya....bit of a chicken and egg, but with the stuff I have done, we have the spec (embedlets), the container RI (outpost) and the sample app (outhouse), so there is a lot to look at and review. The design of the embedlet API's is especially critical. > As soon as I can get a good tagged source tree I'll start creating test > cases built on top of Cork, with some device access... but I want to know what > changes (and how) before I start having to replace my source tree on every > update. No problem....it won't be too long. How about this for a temporary solution......I'll post full source/distribution trees to CVS sooner (ie. this weekend), rather than later. However, I think to keep a handle on things and to minimize the impact on other people's work, we should allocate some responsibilities as to who "owns" certain pieces. The part I'm most worried about is churn in the Embedlet Core Interfaces and Outpost Core Services, which would have widespread impact if the changes are not managed. It seems we have already stratified to a great degree, with you on JAPL, Ted taking the Graphical Wiring (hey Ted....the current Outpost RI has enough dynamic capability that you can already start thinking/working on this!), me on Core (embedlet spec and core Outpost RI services), Chris is very interested in the Persistence Service and Gregg is interested in doing a Mesh inter-system communications service. If we keep this responsibility structure for the moment it will allow us to go forward quickly with a minimum of disruptive impact. Does this make sense? > be careful with Jalopy.. I integrated it into the cork build a little while > ago, but found it caused more problems with my source tree than it was worth, > so instead I have it set up so I can manually format a particular source file > when I'm working on it. If your going to set up it, I suggest you only do it > with an automated CVS commit, and only just before the commit takes place (and > only the files that have changed!) otherwise you get Jalopy resetting all the > files changed or not, and CVS thinks they have changed. I was thinking about those issues....and will see what I can do about them. > Ok, lets check it in, tag it, and we can branch it later if we need to.... I > also suggest a separate branch (or module) for my japl integration, as I don't > know yet just from looking what I will have to do. Make JAPL a separate module. Since I've been keeping everything decoupled and separated, I will create three modules for my source trees, one each for Embedlets, Outpost and Outhouse. > heh... Yah, the age old problem... I find it easier to do brief > documentation, get something working, and go back and document, then do the > next chunk... the long and short is that no matter how much you pre-design > something, you can never actually know its right until you get down to brass > tacks, and make it work. I agree...which is why I went on the spree bouncing back and forth between the spec (embedlets) the RI (outpost) and a test app (outhouse) since it was faster to do this with only one person. But now there is a lot of "meat" in place....and so it needs some peer review. It's not like the code base is just interfaces, since there is a lot of implementation stuff behind it already. Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Andrzej J. T. <an...@ch...> - 2003-03-07 20:45:53
|
Brill notes: > Don't know if its just my system or not, but outpost_003.zip seems to be > corrupt. Might want to check it. Yup...it's corrupted. Ted's upload must have failed part way through. Sorry 'bout that. I've reposted it , so go try it again. Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Brill P. <bri...@ro...> - 2003-03-07 20:18:00
|
> > See my and Bill's post on the CVS repository. We cannot do anything with a zip > > file, without risking overwriting our work. > > Sure you can...it's totally self contained so you can review it and provided > feedback and discussion, which is what I think is needed before we start > hammering out reams of new code/stuff. > > Not gonna post the code base in CVS (since I'm one version ahead) until the > source code formatting (Jalopy) stuff is in place (coming soon) and I start > to see some feedback from the group on the current stuff (up to you guys). Just tag the versions, so they can be reffered to. Thats what the tagging, and branching are for. > Brill chimes in with a similar comment: > > > Would you mind posting the source to CVS rather and the zip files (in a > > proper build environment)? > > Soon as I start to see some feedback on the current stuff. The core > interfaces and design decisions need to be reviewed and agreed before we go > helter skelter building on top of them. I think you'll start getting feedback when we start to actually try to implement test cases... I have the same problem with Cork, where I don't get much feedback, so I don't know if the system is working for anyone ;) As soon as I can get a good tagged source tree I'll start creating test cases built on top of Cork, with some device access... but I want to know what changes (and how) before I start having to replace my source tree on every update. > I also need to get the Jalopy source formatting in place first, to ensure > that all checked in code is in line with the code conventions. be careful with Jalopy.. I integrated it into the cork build a little while ago, but found it caused more problems with my source tree than it was worth, so instead I have it set up so I can manually format a particular source file when I'm working on it. If your going to set up it, I suggest you only do it with an automated CVS commit, and only just before the commit takes place (and only the files that have changed!) otherwise you get Jalopy resetting all the files changed or not, and CVS thinks they have changed. Now... the problem with sourceforge is the darn SSH... I don't know if the ant CVS task can talk to the SSH'ed CVS or not. > Before we cast it in concrete (by building on top of the current interfaces > too much, which will make it much harder to change the underlying contracts), > let's make sure that they are as good as possible, 'cause to do anything else > will compromise our plan to make Embedlets a defacto and distruptive standard > that becomes widely adopted. Ok, lets check it in, tag it, and we can branch it later if we need to.... I also suggest a separate branch (or module) for my japl integration, as I don't know yet just from looking what I will have to do. > The bane of many Open Source projects is the tendency to hack too much code > too early, instead of doing documentation, design review and the like. We've > got enough code now (too much probably, since I'm obviously not immune to the > "let's sling more code" syndrome either ;-) ), and it's time to step back and > ensure that we are going down the optimal path. heh... Yah, the age old problem... I find it easier to do brief documentation, get something working, and go back and document, then do the next chunk... the long and short is that no matter how much you pre-design something, you can never actually know its right until you get down to brass tacks, and make it work. - Brill Pappin Rogue Robotics www.roguerobotics.com |
|
From: Brill P. <bri...@ro...> - 2003-03-07 20:12:56
|
Don't know if its just my system or not, but outpost_003.zip seems to be corrupt. Might want to check it. - Brill Pappin Rogue Robotics www.roguerobotics.com |
|
From: Andrzej J. T. <an...@ch...> - 2003-03-07 19:42:16
|
Chris asks: > When are you going to post the full source tree to the Embedlets repository? > Until you do this it is impossible for anyone else to do any code development. > We will have no revision control until this is done as well. Soon.....in the meantime, the whole source tree is in the zip file.....so go look at it and get the feedback/discussions going! I see that as the next step, since it would be wise to review what currently exists before we go building much on top of it. I may be a decent developer, but I would not suggest that you accept the current stuff on face value alone, flattering though this might be. > I know that it is not your intention to code the complete project yourself! Nope....not enough time nor interest for that. ;-) > See my and Bill's post on the CVS repository. We cannot do anything with a zip > file, without risking overwriting our work. Sure you can...it's totally self contained so you can review it and provided feedback and discussion, which is what I think is needed before we start hammering out reams of new code/stuff. Not gonna post the code base in CVS (since I'm one version ahead) until the source code formatting (Jalopy) stuff is in place (coming soon) and I start to see some feedback from the group on the current stuff (up to you guys). Brill chimes in with a similar comment: > Would you mind posting the source to CVS rather and the zip files (in a > proper build environment)? Soon as I start to see some feedback on the current stuff. The core interfaces and design decisions need to be reviewed and agreed before we go helter skelter building on top of them. I also need to get the Jalopy source formatting in place first, to ensure that all checked in code is in line with the code conventions. > At the moment I've got ant set up to check out the zips, decompress them > into a build dir, etc... but you can't do any diffs, version checking, etc. on > the zip files ;) If you are willing, I will prepare a build env. for you using > the current zipped packages, which you can then modify (I have a bit of spare > time right now). No need, thanks....this is next on my list with the Jalopy stuff and is part way done already. Keep in mind, I posted these releases for DISCUSSION PURPOSES only....not to be used as the basis for further development (yet). My ideas on the interfaces, lifecycle and such are not necessarily the best or the be-all, so need to be reviewed. Besides, before you can start building on new stuff (optional services and the like) you need to understand what is already there, and how it works (eg. how to you structure an Embedlet Service), which should naturally lead to some discussion/review. Let's not get ahead of ourselves, in our rush to develop our favourite kewl component/addition. This first cut was just intended a proof of concept and a kick-start. It SHOULD NOT be accepted as is! Before we cast it in concrete (by building on top of the current interfaces too much, which will make it much harder to change the underlying contracts), let's make sure that they are as good as possible, 'cause to do anything else will compromise our plan to make Embedlets a defacto and distruptive standard that becomes widely adopted. The bane of many Open Source projects is the tendency to hack too much code too early, instead of doing documentation, design review and the like. We've got enough code now (too much probably, since I'm obviously not immune to the "let's sling more code" syndrome either ;-) ), and it's time to step back and ensure that we are going down the optimal path. So please go take a look at what's there....pick it apart...make suggestions....ask questions....critique the interfaces and design choices, as a first step. This shouldn't take long.....but the effort will pay off handsomely down the road. Then we'll be assured that the platform we are building on is optimal as we start to flesh out all the rest of the pieces that need doing (and there are many!). Soon as I get the Jalopy source reformatting tasks running to my satisfaction, I will populate the CVS "properly".....but please....in the meantime, start the review process! Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Andrzej J. T. <an...@ch...> - 2003-03-07 19:19:23
|
> If a person is only interested in deploying outhouse on a TINI right now what > would be the proper way to configure outhouse's build.xml file so that the > build process would not fail because the com.ajile.tools.ant.JemBuilderTask > could not be found? > > When I comment out the following taskdef line in the build.xml file I can run > most of the tasks: > > <taskdef name="JEMBuilder" classname="com.ajile.tools.ant.JemBuilderTask"/> > > but with it in not even the 'help' task will run. So, commenting out this > line works but is there a way to set up the build.xml file so that one does > not need to comment it out? The easy way is to copy the aJileAnt.jar file (found in the /lib dir) into your <ANT_HOME>/lib dir and leave the taskdef in place. This will allow Ant to find the task definition, even though you won't be using it if you don't have an aJile board. Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Christopher S. <cs...@oo...> - 2003-03-07 19:01:34
|
> Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > _______________________________________________ > > Chris asks: > > > Very nice indeed! When can we start building on this? > > See my prior email. > > Right now! Download the latest. Provide feedback/discussion on > the state of > the Embedlet core interfaces/classes and the "design" of the > "spec" to date. See my and Bill's post on the CVS repository. We cannot do anything with a zip file, without risking overwriting our work. > > Also, start designing (and maybe even implementing), optional > services like > Persistence. > > Andrzej Jan Taramina > Chaeron Corporation: Enterprise System Solutions > http://www.chaeron.com > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Etnus, makers of TotalView, > The debugger > for complex code. Debugging C/C++ programs can leave you feeling lost and > disoriented. TotalView can help you find your way. Available on > major UNIX > and Linux platforms. Try it free. www.etnus.com > _______________________________________________ > Embedlets-developer mailing list > Emb...@li... > https://lists.sourceforge.net/lists/listinfo/embedlets-developer > |
|
From: Brill P. <bri...@ro...> - 2003-03-07 18:09:47
|
For a good example of this, see the japl/build.xml When you first build the platform-jstamp module, it will ask you to enter the path to the ajile directiory... it then saves that for future use and adds the aJile runtime to your classpath. - Brill Pappin Rogue Robotics www.roguerobotics.com ----- Original Message ----- From: "Nicola Ken Barozzi" <nic...@ap...> To: <emb...@li...> Sent: Friday, March 07, 2003 2:54 AM Subject: Re: [Embedlets-dev] [outhouse] ant build script > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > _______________________________________________ > > > > Ted Kosan wrote, On 07/03/2003 8.04: > > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > > _______________________________________________ > > > > Andrzej, > > > > If a person is only interested in deploying outhouse on a TINI right now what > > would be the proper way to configure outhouse's build.xml file so that the > > build process would not fail because the com.ajile.tools.ant.JemBuilderTask > > could not be found? > > > > When I comment out the following taskdef line in the build.xml file I can run > > most of the tasks: > > > > <taskdef name="JEMBuilder" classname="com.ajile.tools.ant.JemBuilderTask"/> > > > > but with it in not even the 'help' task will run. So, commenting out this line > > works but is there a way to set up the build.xml file so that one does not need > > to comment it out? > > Try this: > > Use this to see if the class is there: > http://ant.apache.org/manual/CoreTasks/available.html > > Then put the taskdef in a target, call that, and put an if="" attribute > on that target to make it conditional. > > Off the top of my head: > > <!-- set have.JEMBuilder==true if the class is present--> > <available property="have.JEMBuilder" > classname="com.ajile.tools.ant.JemBuilderTask"> > <classpath> > <fileset dir="lib"> > <include name="**/*.jar"/> > </fileset> > </classpath> > </available> > > <antcall target="load.JEMBuilder"> > ... > > and make: > > <target name="load.JEMBuilder" if="have.JEMBuilder"> > <taskdef name="JEMBuilder" > classname="com.ajile.tools.ant.JemBuilderTask"/> > </target> > > -- > Nicola Ken Barozzi nic...@ap... > - verba volant, scripta manent - > (discussions get forgotten, just code remains) > --------------------------------------------------------------------- > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger > for complex code. Debugging C/C++ programs can leave you feeling lost and > disoriented. TotalView can help you find your way. Available on major UNIX > and Linux platforms. Try it free. www.etnus.com > _______________________________________________ > Embedlets-developer mailing list > Emb...@li... > https://lists.sourceforge.net/lists/listinfo/embedlets-developer > |
|
From: Brill P. <bri...@ro...> - 2003-03-07 17:33:02
|
Hi Andrzej, Would you mind posting the source to CVS rather and the zip files (in a proper build environment)? At the moment I've got ant set up to check out the zips, decompress them into a build dir, etc... but you can't do any diffs, version checking, etc. on the zip files ;) If you are willing, I will prepare a build env. for you using the current zipped packages, which you can then modify (I have a bit of spare time right now). Also, I don't know if anyone else if having trouble with this, but please change the "release" module as it's a little ambiguous when your working on several different projects (particularly in Eclipse). - Brill Pappin Rogue Robotics www.roguerobotics.com ----- Original Message ----- From: "Andrzej Jan Taramina" <an...@ch...> To: <emb...@li...> Sent: Thursday, March 06, 2003 1:14 PM Subject: [Embedlets-dev] Here is the announcement.... > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > _______________________________________________ > > ...that will go up as soon as I (or you) manage to get the stuff posted to > CVS. > > Just thought you might want to know, so you could "play" earlier. ;-) > > > .....A > > ------------------------------------------------ > > I just posted the next release of all the code and executables in the release > directory in the CVS repository. > > There are 3 zip files you can download: > > embedlet_003.zip The core interfaces/contracts/base classes (the spec), > Ver 0.03 > > outpost_003.zip The Outpost Container Reference Implementation. > Ver 0.03 > > outhouse_001.zip The sample application (embedlet pipeline). Ready to run! > > Each archive is independent of the others. If all you want to do is to run > the test application, all you need is Outhouse. > > This set of releases will build and run on Windows, Linux, aJile > (JStamp/SaJe) and TINI! You can run Outhouse on any of these platforms. The > binary builds of Outhouse for aJile/TINI are not included to keep the > distribution sizes down, but there are Ant targets that will let you build > them easily. Be sure to read the devnotes.txt file in theOuthouse /doc > subdir if you want to run on these embedded platforms since you'll have to > modify the build.properties file (to point to where you have your aJile/TINI > SDK's installed) and on editing the aJile .ajp files. > > Check the respective history.html files (in the /doc subdirs) for what's new. > > Major stuff added in this set of releases: > > 1) Implementation of the Outpost Timer Service (both one shot and periodic > timers). > > 2) Implementation of event type matching and wildcard capability > > 3) Move of the sample application code into the Outhouse archive (no longer > part of the Outpost distribution). > > 4) Change of the sample application to use the Timer Service to drive the > ProducerEmbedlet event production process. > > > > Andrzej Jan Taramina > Chaeron Corporation: Enterprise System Solutions > http://www.chaeron.com > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger > for complex code. Debugging C/C++ programs can leave you feeling lost and > disoriented. TotalView can help you find your way. Available on major UNIX > and Linux platforms. Try it free. www.etnus.com > _______________________________________________ > Embedlets-developer mailing list > Emb...@li... > https://lists.sourceforge.net/lists/listinfo/embedlets-developer > |
|
From: Andrzej J. T. <an...@ch...> - 2003-03-07 14:20:05
|
Chris asks: > Very nice indeed! When can we start building on this? See my prior email. Right now! Download the latest. Provide feedback/discussion on the state of the Embedlet core interfaces/classes and the "design" of the "spec" to date. Also, start designing (and maybe even implementing), optional services like Persistence. Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Andrzej J. T. <an...@ch...> - 2003-03-07 14:19:58
|
Chris proposes: > Just checking to see if the Emperor has clothes on! Much though it embarasses me, in the interests of being collegial, I shall accept the role of "Embedlet Emperor" as you suggest. It does have a certain ring to it, non? ;-) > Let me know where I (or anyone else) can pitch in - I know you are having fun > but this is a collaborative project! Sorry.....it's not my intention to hog it all, was just trying to make use of some spare time (that goes away next week) and kickstart us. As for where to help, two major areas come to mind: 1) COMMENTS/SUGGESTIONS on what is already in place. Primarily on the Embedlet interfaces/core classes (the "spec"). Areas of improvement? Areas of extension? Refactorings? The Outpost RI is probably not so critical at this point (for critique) as the spec portion. So go download the latest.....snoop around....ask questions......make suggestions! That is what will improve things the most right now. 2) Start designing the interfaces/contracts (and maybe prelim implementation) of optional services, based on the existing API's, and RI. Persistence Service, Chris? Mesh Service, Gregg? Feedback and discussion is what we need the most at this stage.... Thanks! Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Andrzej J. T. <an...@ch...> - 2003-03-07 14:19:54
|
Chris observes: > That all makes sense for events that can afford to fail (logs, user > interaction etc.) For those that cannot there needs to be a queue-bypass > path that can complete in a given amount of time. Fortunately the > synchronous event stack depth would be deterministic since a given event > would have a known path based on the consumers that are registered. The > last event in the path may be asynchronous as in a logging event, user > notification. This mix and match of sync/async events is central to real > time operation with external client processes. I absolutely agree....and Synchronous event sending is now implemented. The next version to go up (this weekend) will have that in place. > But you would use an interrupt driven event to notify critical embedlets > that something needs to be done NOW! This kind of event could occur on > sub-millisecond to an hour or more interval. The important thing is that > there is a mechanism to define the mission critical event and guarantee > its immediate delivery. This way the developer does not have to 'punt' too > early in the game because Embedlets cannot deliver! Yup....but I see the interrupt-generation and initial receipt as being a device driver issue (JAPL?) which will then send a Synchronous event to an Embedlet to do something useful with the interrupt notification. I'll give some thought to a way of grabbing a global async thread lock so that all other threads get blocked while the synchronous event is being propagated, for the ultra-critical events. Otherwise, even a synchronous event propagation can be pre-empted by an async thread execution. > This makes the most sense in core Embedlet communication. This makes the > 'wires' a solid connection between produce and consumers and ensures > prompt processing of events. Async events will be very important as well > to off load communication between more loosely coupled processes to lower > priority services. Yup! And we now have both. > We should probably put together a 'When to use Sync/Async events' document > based on this discussion thread. For sure....this would be very useful. Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Christopher S. <cs...@oo...> - 2003-03-07 09:10:12
|
Andrzej, When are you going to post the full source tree to the Embedlets repository? Until you do this it is impossible for anyone else to do any code development. We will have no revision control until this is done as well. I know that it is not your intention to code the complete project yourself! Chris > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > _______________________________________________ > > ...that will go up as soon as I (or you) manage to get the stuff > posted to > CVS. > > Just thought you might want to know, so you could "play" earlier. ;-) > > > .....A > > ------------------------------------------------ > > I just posted the next release of all the code and executables in > the release > directory in the CVS repository. > > There are 3 zip files you can download: > > embedlet_003.zip The core interfaces/contracts/base > classes (the spec), > Ver 0.03 > > outpost_003.zip The Outpost Container Reference > Implementation. > Ver 0.03 > > outhouse_001.zip The sample application (embedlet > pipeline). Ready to run! > > Each archive is independent of the others. If all you want to do > is to run > the test application, all you need is Outhouse. > > This set of releases will build and run on Windows, Linux, aJile > (JStamp/SaJe) and TINI! You can run Outhouse on any of these > platforms. The > binary builds of Outhouse for aJile/TINI are not included to keep the > distribution sizes down, but there are Ant targets that will let > you build > them easily. Be sure to read the devnotes.txt file in theOuthouse /doc > subdir if you want to run on these embedded platforms since > you'll have to > modify the build.properties file (to point to where you have your > aJile/TINI > SDK's installed) and on editing the aJile .ajp files. > > Check the respective history.html files (in the /doc subdirs) for > what's new. > > Major stuff added in this set of releases: > > 1) Implementation of the Outpost Timer Service (both one shot and > periodic > timers). > > 2) Implementation of event type matching and wildcard capability > > 3) Move of the sample application code into the Outhouse archive > (no longer > part of the Outpost distribution). > > 4) Change of the sample application to use the Timer Service to drive the > ProducerEmbedlet event production process. > > > > Andrzej Jan Taramina > Chaeron Corporation: Enterprise System Solutions > http://www.chaeron.com > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Etnus, makers of TotalView, > The debugger > for complex code. Debugging C/C++ programs can leave you feeling lost and > disoriented. TotalView can help you find your way. Available on > major UNIX > and Linux platforms. Try it free. www.etnus.com > _______________________________________________ > Embedlets-developer mailing list > Emb...@li... > https://lists.sourceforge.net/lists/listinfo/embedlets-developer > |
|
From: Nicola K. B. <nic...@ap...> - 2003-03-07 07:54:57
|
Ted Kosan wrote, On 07/03/2003 8.04: > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > _______________________________________________ > > Andrzej, > > If a person is only interested in deploying outhouse on a TINI right now what > would be the proper way to configure outhouse's build.xml file so that the > build process would not fail because the com.ajile.tools.ant.JemBuilderTask > could not be found? > > When I comment out the following taskdef line in the build.xml file I can run > most of the tasks: > > <taskdef name="JEMBuilder" classname="com.ajile.tools.ant.JemBuilderTask"/> > > but with it in not even the 'help' task will run. So, commenting out this line > works but is there a way to set up the build.xml file so that one does not need > to comment it out? Try this: Use this to see if the class is there: http://ant.apache.org/manual/CoreTasks/available.html Then put the taskdef in a target, call that, and put an if="" attribute on that target to make it conditional. Off the top of my head: <!-- set have.JEMBuilder==true if the class is present--> <available property="have.JEMBuilder" classname="com.ajile.tools.ant.JemBuilderTask"> <classpath> <fileset dir="lib"> <include name="**/*.jar"/> </fileset> </classpath> </available> <antcall target="load.JEMBuilder"> ... and make: <target name="load.JEMBuilder" if="have.JEMBuilder"> <taskdef name="JEMBuilder" classname="com.ajile.tools.ant.JemBuilderTask"/> </target> -- Nicola Ken Barozzi nic...@ap... - verba volant, scripta manent - (discussions get forgotten, just code remains) --------------------------------------------------------------------- |
|
From: Ted K. <tk...@ya...> - 2003-03-07 07:04:26
|
Andrzej, If a person is only interested in deploying outhouse on a TINI right now what would be the proper way to configure outhouse's build.xml file so that the build process would not fail because the com.ajile.tools.ant.JemBuilderTask could not be found? When I comment out the following taskdef line in the build.xml file I can run most of the tasks: <taskdef name="JEMBuilder" classname="com.ajile.tools.ant.JemBuilderTask"/> but with it in not even the 'help' task will run. So, commenting out this line works but is there a way to set up the build.xml file so that one does not need to comment it out? Ted __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ |
|
From: Andrzej J. T. <an...@ch...> - 2003-03-07 04:33:10
|
Hi all: I just posted the next release of all the code and executables in the release directory in the CVS repository. There are 3 zip files you can download: embedlet_003.zip The core interfaces/contracts/base classes (the spec), Ver 0.03 outpost_003.zip The Outpost Container Reference Implementation. Ver 0.03 outhouse_001.zip The sample application (embedlet pipeline). Ready to run! Each archive is independent of the others. If all you want to do is to run the test application, all you need is Outhouse. This set of releases will build and run on Windows, Linux, aJile (JStamp/SaJe) and TINI! You can run Outhouse on any of these platforms. The binary builds of Outhouse for aJile/TINI are not included to keep the distribution sizes down, but there are Ant targets that will let you build them easily. Be sure to read the devnotes.txt file in theOuthouse /doc subdir if you want to run on these embedded platforms since you'll have to modify the build.properties file (to point to where you have your aJile/TINI SDK's installed) and on editing the aJile .ajp files. Check the respective history.html files (in the /doc subdirs) for what's new. Major stuff added in this set of releases: 1) Implementation of the Outpost Timer Service (both one shot and periodic timers). 2) Implementation of event type matching and wildcard capability 3) Move of the sample application code into the Outhouse archive (no longer part of the Outpost distribution). 4) Change of the sample application to use the Timer Service to drive the ProducerEmbedlet event production process. Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Andrzej J. T. <an...@ch...> - 2003-03-07 03:42:18
|
It was bugging me, so I did some investigation, and found that one particular operation was killing the TINI performance, and that was accessing various component property values during the event propagation process. I refactored that so that Components (eg. Embedlets) cache their static values in instance variables (things like the unique ID, description, version, etc.) and also refactored how Lifecycle state was get/set in a similar manner. Here were the results, comparing async and sync event propagation (all values in events/second) before and after the refactorings: PLATFORM ASYNC SYNC (Recycled) SYNC (Non-Recycled) TINI (before): 8 13 143 TINI (after): 12 71 133 As you can see, the Async speed improved by 50%. The Sync speed using recycled event instances (so only one is ever created) was markedly improved by the refactoring. The Sync (Non-recycled) slowed down a trifle due to some other refactoring that I put in place to improve the Embedlet spec interfaces a bit, but the net loss in speed was only about 7% (and those structural refactorings were necessary). I figure the SYNC (Non-Recycled) is running about as fast as the poor TINI can go, and though there might be some minor tweaking that could possibly help a bit, that's about all she wrote. With the new refactorings, the SYNC (Recycled) path is probably approaching optimum as well. However, the Async is still quite disappointing. Sure it's using threads and thread context switches, but I think it should be a bit closer to the SYNC (Recycled) performance. My gut feel is that this can probably be improved a fair bit by optimizing the queue structures (away from generic Vectors and Hashtables to more customized versions that are specifically tuned to the access patterns that async event propagation produces). So there is still lots of room there I think. Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Christopher S. <cs...@oo...> - 2003-03-07 02:05:32
|
> > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > _______________________________________________ > > I added an optimization, since if you are using Sync events, the > component > (Embedlet) knows upon return of the send() method, all consumers have > received the event, and so it's now possible to flag a sync event > instance as > non-recycleable, and thus the component can create one event and > keep reusing > it for all future sends (since the container won't try to recycle it). This makes the most sense in core Embedlet communication. This makes the 'wires' a solid connection between produce and consumers and ensures prompt processing of events. Async events will be very important as well to off load communication between more loosely coupled processes to lower priority services. We should probably put together a 'When to use Sync/Async events' document based on this discussion thread. > > In the benchmark example, this means the ProducerEmbedlet just creates a > single event and then sends it 1000 times in the non-recycled case. > > Assuming fairly accurate processor clocks, here were the results, > comparing async and sync event > propagation (all values in events/second) > > PLATFORM ASYNC SYNC > (Recycled) SYNC (Non-Recycled) > > PC/Windows (400 mhz): 2800 16.7K > 50K > > SaJe (aJile aJ-100): 3940 > 10.7K 43.5K > > JStamp( aJile aJ-80): 652 > 2000 7350 > > TINI: 8 > 13 143 > > What the non-recycled case does is eliminate some setter methods on the > event, along with elimination of the hashtable lookup of the > event type (in > string form, eg "event.producer") into an internal event typeID > (long). I'll > bet that the hashtable implementations coupled with the string > compares they > do (eg. str1.equals( str2 ) ) are taking a lot of processor time, and are > especially inefficient on the TINI. > > This points to some potential optimizations that can be done down > the road > that will speed the Async and recycled Sync event propagation paths. > > However, I think I'm gonna leave that till later, since I want to work on > some other things before we start getting too tied up in low level > optimizations. > Andrzej Jan Taramina > Chaeron Corporation: Enterprise System Solutions > http://www.chaeron.com > > I think that it is certainly good enough to release for version 0.0.3 :-) Very impressive indeed! > > ------------------------------------------------------- > This SF.net email is sponsored by: Etnus, makers of TotalView, > The debugger > for complex code. Debugging C/C++ programs can leave you feeling lost and > disoriented. TotalView can help you find your way. Available on > major UNIX > and Linux platforms. Try it free. www.etnus.com > _______________________________________________ > Embedlets-developer mailing list > Emb...@li... > https://lists.sourceforge.net/lists/listinfo/embedlets-developer > |
|
From: Andrzej J. T. <an...@ch...> - 2003-03-07 00:32:37
|
I added an optimization, since if you are using Sync events, the component (Embedlet) knows upon return of the send() method, all consumers have received the event, and so it's now possible to flag a sync event instance as non-recycleable, and thus the component can create one event and keep reusing it for all future sends (since the container won't try to recycle it). In the benchmark example, this means the ProducerEmbedlet just creates a single event and then sends it 1000 times in the non-recycled case. Assuming fairly accurate processor clocks, here were the results, comparing async and sync event propagation (all values in events/second) PLATFORM ASYNC SYNC (Recycled) SYNC (Non-Recycled) PC/Windows (400 mhz): 2800 16.7K 50K SaJe (aJile aJ-100): 3940 10.7K 43.5K JStamp( aJile aJ-80): 652 2000 7350 TINI: 8 13 143 What the non-recycled case does is eliminate some setter methods on the event, along with elimination of the hashtable lookup of the event type (in string form, eg "event.producer") into an internal event typeID (long). I'll bet that the hashtable implementations coupled with the string compares they do (eg. str1.equals( str2 ) ) are taking a lot of processor time, and are especially inefficient on the TINI. This points to some potential optimizations that can be done down the road that will speed the Async and recycled Sync event propagation paths. However, I think I'm gonna leave that till later, since I want to work on some other things before we start getting too tied up in low level optimizations. Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Ted K. <tk...@ya...> - 2003-03-07 00:00:47
|
Andrzej was having difficulties with posting the updated Embedlets release to the CVS so he emailed the files to me and I uploaded them. Ted __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ |
11 messages has been excluded from this view by a project administrator.
Thanks for helping keep SourceForge clean.
X