embedlets-developer Mailing List for Outpost Embedlet Container (Page 20)
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: Brill P. <bri...@ro...> - 2003-03-06 23:38:25
|
> The JCP seems to be a way to hold back the force of Microsoft through joint > effort, but unless you are backed by a company large enough to drop $5000 to > buy a seat on the Security Counsel you will not have much influence. It's kind of unfortunate... I mean we are the folks who are pioneering this sort of development... but I guess all human endeavours have some sort of politics attached. - Brill |
|
From: Christopher S. <cs...@oo...> - 2003-03-06 23:35:25
|
> Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > _______________________________________________ > Very nice indeed! When can we start building on this? Chris > Chris suggested: > > > Do you think that synchronous processing would make a significant > > difference? > > And so I implemented Synchronous event propagation and reran the > benchmarks... > > The benchmark consisted of two Embedlets. A Producer and a Consumer. The > producer ran through a loop and generated 1000 events, and the > Consumer just > received these asynchronously. Just before the start of the loop > I would grab > the time (in milliseconds) and then would grab it again after the > Consumer > received it's 1000th event and calculate some statistics. Neither the > Producer nor the consumer did anything more than that with the events > sent/received. Note that each platform still had a number of > threads running (1 EventDispatcher, 5 > EventSenders and 1 TimerDispatcher), even though they had nothing to do. > > Assuming fairly accurate processor clocks, here were the results, > comparing async and sync event > propagation (all values in events/second) > > PLATFORM ASYNC SYNC > > PC/Windows (400 mhz): 2800 16.7K > > SaJe (aJile aJ-100): 3940 10.7K > > JStamp( aJile aJ-80): 652 2000 > > TINI: 8 > 13 > > Some marked improvements in event propagation speed in going to a > synchronous > model. However, I was rather hoping for a more dramatic > improvement on the > TINI, but it only improved about 63% (still nothing to sneeze > at), whereas > the other platforms had more dramatic improvements. I wonder if the idle > threads (even though the threads would all be in wait() state) > has anything > to do with the poor TINI performance? I'll have to investigate at some > point. > > SaJe and JStamp still show a 5-1 ratio with sync events, as was > expected. > > Anyway.....some more intriguing results, n'est-ce pas? > > > What would you like to see next, Chris? <grins> > 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-06 23:32:58
|
> Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > _______________________________________________ > > Brill states: > > > I think what needs to happen is to get it submitted to the JCP, to help > > generate awareness, and give companies like aJile and Dallas, etc. more > > incentive. > > I'm on an Expert Commitee for a JSR (JCP process for Location > based API, GPS > stuff and all). These committee's are very political and > typically driven by > the big companies participating. I would caution against using the JCP > process unless you want to slow down progress and maybe even give up any > influence on it altogether. > > I would suggest that we approach aJile, Dallas and others directly, as a > united group, to "sell" them on the concept of Embedlets and JAPL > and try to > get them to sponsor the development/standardization effort by donating > people/time/money/resources directly to the effort rather than > pursuing a JCP- > based process at this time. > > Very soon we'll have enough working code, standards and the like that we > should be able to make quite an impact. I agree. The JCP seems to be a way to hold back the force of Microsoft through joint effort, but unless you are backed by a company large enough to drop $5000 to buy a seat on the Security Counsel you will not have much influence. Chris Smith > > 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-06 23:22:49
|
> > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > _______________________________________________ > > Chris notes: > > (he asks for benchmarks, and he gets benchmarks, and what does he do? > whine...whine...whine some more. <wide grins>). Just checking to see if the Emperor has clothes on! > > > Do you think that synchronous processing would make a significant > > difference? > > Yes. I just haven't implemented synchronous sends yet, but it's > coming soon! > > I plan to rerun the benchmarks with synch events to see how much > improvement > it might generate, and will post the results when I get there. Let me know where I (or anyone else) can pitch in - I know you are having fun but this is a collaborative project! > > > With synchronous processing there are no thread creation/switch > > issues and any contention for the queue is eliminated. The > queued events may > > have none-deterministic performance behavior if there are multiple, > > independent producers throwing events around. I could see a mix > of the two: > > The issue with synchronous events is that you end up replacing > the explicit > queue with the system stack instead. Nothing wrong with > that...but it can be > harder to control memory usage that way (ie. recursion depth). > The Outpost > event queues can already be configured with warning and error max > sizes, so > that you can limit the growth if you want/need to. 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. > > > 1. Asynchronous for low priority, external interfaces where the > producers > > should not block, waiting for completion. 2. Synchronous for > high priority, > > interrupt driven processes that require guaranteed response times. > > Yup....though I think in many cases that high priority, interrupt driven > processes that require guaranteed response times probably will need to be > handled in the device driver level with a high priority, > pre-empting thread > and thus would end up invisible to the Embedlet application code. For > example, I don't think you would use an Embedlet to generate a high speed > pulse stream on an GPIO pin. 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! > > 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-06 23:07:00
|
> > I think what needs to happen is to get it submitted to the JCP, to help > > stuff and all). These committee's are very political and typically driven by > the big companies participating. I would caution against using the JCP > process unless you want to slow down progress and maybe even give up any > influence on it altogether. Yes, thats what I meant by "i'm very new"... like diving into a shark pool! ;) > I would suggest that we approach aJile, Dallas and others directly, as a > united group, to "sell" them on the concept of Embedlets and JAPL and try to > get them to sponsor the development/standardization effort by donating > people/time/money/resources directly to the effort rather than pursuing a JCP- > based process at this time. Actually... it might even be better to try and "sell" it on our own, to the *users*... as they demand better implementations etc, the "big boys" will pay more attention when we approach them. Anyway, I'm simply not a "polit·T guy ;) so I'm staying out of the JCP for the moment :) - Brill |
|
From: Andrzej J. T. <an...@ch...> - 2003-03-06 21:04:32
|
Chris suggested: > Do you think that synchronous processing would make a significant > difference? And so I implemented Synchronous event propagation and reran the benchmarks... The benchmark consisted of two Embedlets. A Producer and a Consumer. The producer ran through a loop and generated 1000 events, and the Consumer just received these asynchronously. Just before the start of the loop I would grab the time (in milliseconds) and then would grab it again after the Consumer received it's 1000th event and calculate some statistics. Neither the Producer nor the consumer did anything more than that with the events sent/received. Note that each platform still had a number of threads running (1 EventDispatcher, 5 EventSenders and 1 TimerDispatcher), even though they had nothing to do. Assuming fairly accurate processor clocks, here were the results, comparing async and sync event propagation (all values in events/second) PLATFORM ASYNC SYNC PC/Windows (400 mhz): 2800 16.7K SaJe (aJile aJ-100): 3940 10.7K JStamp( aJile aJ-80): 652 2000 TINI: 8 13 Some marked improvements in event propagation speed in going to a synchronous model. However, I was rather hoping for a more dramatic improvement on the TINI, but it only improved about 63% (still nothing to sneeze at), whereas the other platforms had more dramatic improvements. I wonder if the idle threads (even though the threads would all be in wait() state) has anything to do with the poor TINI performance? I'll have to investigate at some point. SaJe and JStamp still show a 5-1 ratio with sync events, as was expected. Anyway.....some more intriguing results, n'est-ce pas? What would you like to see next, Chris? <grins> Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Andrzej J. T. <an...@ch...> - 2003-03-06 20:01:32
|
Brill states: > I think what needs to happen is to get it submitted to the JCP, to help > generate awareness, and give companies like aJile and Dallas, etc. more > incentive. I'm on an Expert Commitee for a JSR (JCP process for Location based API, GPS stuff and all). These committee's are very political and typically driven by the big companies participating. I would caution against using the JCP process unless you want to slow down progress and maybe even give up any influence on it altogether. I would suggest that we approach aJile, Dallas and others directly, as a united group, to "sell" them on the concept of Embedlets and JAPL and try to get them to sponsor the development/standardization effort by donating people/time/money/resources directly to the effort rather than pursuing a JCP- based process at this time. Very soon we'll have enough working code, standards and the like that we should be able to make quite an impact. Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Andrzej J. T. <an...@ch...> - 2003-03-06 19:59:17
|
Chris notes: (he asks for benchmarks, and he gets benchmarks, and what does he do? whine...whine...whine some more. <wide grins>). > Do you think that synchronous processing would make a significant > difference? Yes. I just haven't implemented synchronous sends yet, but it's coming soon! I plan to rerun the benchmarks with synch events to see how much improvement it might generate, and will post the results when I get there. > With synchronous processing there are no thread creation/switch > issues and any contention for the queue is eliminated. The queued events may > have none-deterministic performance behavior if there are multiple, > independent producers throwing events around. I could see a mix of the two: The issue with synchronous events is that you end up replacing the explicit queue with the system stack instead. Nothing wrong with that...but it can be harder to control memory usage that way (ie. recursion depth). The Outpost event queues can already be configured with warning and error max sizes, so that you can limit the growth if you want/need to. > 1. Asynchronous for low priority, external interfaces where the producers > should not block, waiting for completion. 2. Synchronous for high priority, > interrupt driven processes that require guaranteed response times. Yup....though I think in many cases that high priority, interrupt driven processes that require guaranteed response times probably will need to be handled in the device driver level with a high priority, pre-empting thread and thus would end up invisible to the Embedlet application code. For example, I don't think you would use an Embedlet to generate a high speed pulse stream on an GPIO pin. Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Andrzej J. T. <an...@ch...> - 2003-03-06 18:55:22
|
...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 |
|
From: Gregg G. W. <gr...@sk...> - 2003-03-06 06:06:22
|
>Do you think that synchronous processing would make a significant >difference? With synchronous processing there are no thread creation/switch >issues and any contention for the queue is eliminated. The queued events may >have none-deterministic performance behavior if there are multiple, >independent producers throwing events around. I could see a mix of the two: > >1. Asynchronous for low priority, external interfaces where the producers >should not block, waiting for completion. >2. Synchronous for high priority, interrupt driven processes that require >guaranteed response times. My space implementation that Andrzej is looking at makes exactly these features possible. It lets you create a 'mesh' that removes duplicate data. It uses a Thread pool to relay to other spaces. So, you create a local space for local events, and everything is synchronous (gotta watchout for RuntimeException!). If you connect another space for external events, it gets fed by Threads. Gluing Andrzej's queues inbetween internal and external spaces would hold off thread explosions that small devices hate... ----- gr...@cy... (Cyte Technologies Inc) |
|
From: Christopher S. <cs...@oo...> - 2003-03-06 05:50:51
|
> > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > _______________________________________________ > > Chris suggested: > > > It would be interesting to see what performance you are getting on the > > event queue with the three platforms. The parameter to measure would be > > the producer-event-consumer cycle and then we could calculate the > > potential number of events per second. > > And of course, the groups wish is my command, so I did up some benchmarks. > > The benchmark consisted of two Embedlets. A Producer and a Consumer. The > producer ran through a loop and generated 1000 events, and the > Consumer just > received these asynchronously. Just before the start of the loop > I would grab > the time (in milliseconds) and then would grab it again after the > Consumer > received it's 1000th event and calculate some statistics. Neither the > Producer nor the consumer did anything more than that with the events > sent/received. > > Assuming fairly accurate processor clocks, here were the results. > > PC/Windows (400 mhz): ~2800 events/second > > SaJe (aJile aJ-100): ~3940events/second > > JStamp( aJile aJ-80): ~652events/second > > TINI: ~8 events/second > > Funny that the SaJe board is faster than my 400 mhz Pentium! ;-) > > The SaJe is about 5-6x times faster than the JStamp, which given > the relative > speed of bytecode execution on the two processors, is about right. > > What is a bit disconcerting is the poor performance of the TINI. > According > to James' benchmarks (which only measure very simple bytecode > performance, > and not thread context switches, garbage collection speed, object > creation > speed and probably all sorts of other real world, expensive > operations that > Embedlets will encounter), the TINI should have run about 15 times slower > than the JStamp. But the results show the TINI as about 80x > slower than a > JStamp. Ouch! > > According to Bruce's stats, the JStamp will do a thread switch in about 8 > usec whereas the TINI will take 2msec. That's a 250x difference > and might be > accounting for some of the variance and poor performance with the TINI. > > There was very little object creation going on with the benchmark, since > event objects were recycled. > > I'll have to take a look at the detailed execution paths and see > if there is > anything that I can do to improve performance on the TINI. It > could be that > optimizing the queues (to use something a bit more efficient than > Vectors) > might provide a lot of benefit on the TINI. > > Anyway.....some very intriguing results, n'est-ce pas? Qui, Do you think that synchronous processing would make a significant difference? With synchronous processing there are no thread creation/switch issues and any contention for the queue is eliminated. The queued events may have none-deterministic performance behavior if there are multiple, independent producers throwing events around. I could see a mix of the two: 1. Asynchronous for low priority, external interfaces where the producers should not block, waiting for completion. 2. Synchronous for high priority, interrupt driven processes that require guaranteed response times. > > 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-06 04:45:32
|
> SaJe (aJile aJ-100): ~3940events/second > > JStamp( aJile aJ-80): ~652events/second > > TINI: ~8 events/second > > Funny that the SaJe board is faster than my 400 mhz Pentium! ;-) > > The SaJe is about 5-6x times faster than the JStamp, which given the relative > speed of bytecode execution on the two processors, is about right. This is right in line with the SYstronix/aJile claims of 5 time faster code on the aj-100... it shows up in the systronix benchmarks as well. > What is a bit disconcerting is the poor performance of the TINI. According This is not actually all that surprising as well (and is also predicted by the systronix benchmark). I think its important to remember that the TINI is not really a java processor. > According to Bruce's stats, the JStamp will do a thread switch in about 8 > usec whereas the TINI will take 2msec. That's a 250x difference and might be > accounting for some of the variance and poor performance with the TINI. I suspect that you seeing slower speeds because there will be a lot of things that the Systronix benchmarks *don't* cover... in their tests, they are running fairly simple code, however what your doing is much more in-line with real-world code, including GC and object creation, even if you recycle them, you still doing a lot of "extra" work on the TINI. > I'll have to take a look at the detailed execution paths and see if there is > anything that I can do to improve performance on the TINI. It could be that > optimizing the queues (to use something a bit more efficient than Vectors) > might provide a lot of benefit on the TINI. Try using primitive types where possible... no strings. I have run into the same problems with Cork... in fact the JAPL doesn't use string as all, it does support properties, but instead of naming them, I've used int constants (been thinking of using char arrays instead of int's but haven't yet). Anyway instead of using strings for naming contexts, labelling events, etc., try char arrays (which should also make things easier on controllers like the uVM). You may not gain all that much (a little memory, and a little processing) but if you don't manipulate them yourself, your depending on the underlying java code to do the same job for you, which doesn't know your application and may have extra steps, or use extra memory with buffers or what-not. Of course, it may just not help ;) since you still have to deal with the threads, which on TINI only *get* a 2ms execution block (If I remember correctly, it's a 2ms round-robin). - Brill Pappin |
|
From: Andrzej J. T. <an...@ch...> - 2003-03-06 04:03:25
|
..The Outpost Reference Implementation Timer Service lives and supports both one shot and periodic timer events. I'm pretty close to posting the next release. Just FYI.... Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Andrzej J. T. <an...@ch...> - 2003-03-06 04:02:18
|
Chris suggested: > It would be interesting to see what performance you are getting on the > event queue with the three platforms. The parameter to measure would be > the producer-event-consumer cycle and then we could calculate the > potential number of events per second. And of course, the groups wish is my command, so I did up some benchmarks. The benchmark consisted of two Embedlets. A Producer and a Consumer. The producer ran through a loop and generated 1000 events, and the Consumer just received these asynchronously. Just before the start of the loop I would grab the time (in milliseconds) and then would grab it again after the Consumer received it's 1000th event and calculate some statistics. Neither the Producer nor the consumer did anything more than that with the events sent/received. Assuming fairly accurate processor clocks, here were the results. PC/Windows (400 mhz): ~2800 events/second SaJe (aJile aJ-100): ~3940events/second JStamp( aJile aJ-80): ~652events/second TINI: ~8 events/second Funny that the SaJe board is faster than my 400 mhz Pentium! ;-) The SaJe is about 5-6x times faster than the JStamp, which given the relative speed of bytecode execution on the two processors, is about right. What is a bit disconcerting is the poor performance of the TINI. According to James' benchmarks (which only measure very simple bytecode performance, and not thread context switches, garbage collection speed, object creation speed and probably all sorts of other real world, expensive operations that Embedlets will encounter), the TINI should have run about 15 times slower than the JStamp. But the results show the TINI as about 80x slower than a JStamp. Ouch! According to Bruce's stats, the JStamp will do a thread switch in about 8 usec whereas the TINI will take 2msec. That's a 250x difference and might be accounting for some of the variance and poor performance with the TINI. There was very little object creation going on with the benchmark, since event objects were recycled. I'll have to take a look at the detailed execution paths and see if there is anything that I can do to improve performance on the TINI. It could be that optimizing the queues (to use something a bit more efficient than Vectors) might provide a lot of benefit on the TINI. Anyway.....some very intriguing results, n'est-ce pas? Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Brill P. <bri...@ro...> - 2003-03-05 23:43:32
|
> My thinking on JAPL is that perhaps it would be a good idea for us to develop a > few of the 'low hanging fruit' JAPL peripherals so that we can demonstrate to > people how they work. Then maybe we can try to bring some companies like > Ajile, Dallas Semiconductor, etc. together (kind of like the JCP does) so that > these interfaces can be hammered out at a company level. I'm about to start on some 1-Wire devices that you can test with... unfortunatly I can't use the 1-Wire interface directly if we want to stay abstract, I'm going to have to wrap it in another interface layer... but thats a Cork problem, not a JAPL problem specifically, except where the Cork api interfaces using JAPL. > I think that perhaps companies would be more willing to support JAPL in their > APIs if they actually participated in their development. I agree... in fact, I'd rather not have to deal with designing it at all (been too busy lately, and they would have more invested in doing it). I think what needs to happen is to get it submitted to the JCP, to help generate awareness, and give companies like aJile and Dallas, etc. more incentive. I've been thinking of doing that myself, but I'm fairly new the JCP and wanted to work out some of the problems with it... What I've found is that because it's not Cork specific there is a lot of "wastage" however the abstraction is required in order to support the multitude of different peripherals avalilbe. Originally I based it on the 1-Wire API, as that is fairly clean (could be better, but not bad) but when I got right into it I found it too limiting (specific).... anyway, what came out of that way a hybred where *function* is abstracted rather than *purpose* which is not really what we had intended when we started it. > Aside from this, over the weekend I will try to download the materials you > submitted and take a look at them. keep in mind that nothing has been tested very well, and you might no even be able to get it to run on the processors... this is coming, and Cork used to run on the JStamp, but with the sever API changes required to plug in the JAPL, I can't be sure it will. Also, not all Cork devices have their JAPL interfaces implemented... but I'm working on it :) - Brill Pappin |
|
From: Gregg G. W. <gr...@sk...> - 2003-03-05 22:46:23
|
>Oh....and the answer is 42! > > >.....Zaphod 42 is always the last octet of the IP address I use on any network :-) ----- gr...@cy... (Cyte Technologies Inc) |
|
From: Ted K. <tk...@ya...> - 2003-03-05 22:27:09
|
Brill wrote, > As for JAPL... I went though several iterations, and found the task much > more difficult than it may first appear... the structure (javadocs in > dist/docs/api after dist target is run) that I have there now came after > long deliberation trying to fit the api into the truly abstract nature we're > targeting... however it can be improved... the main hurdle is that there are > so many devices, with so many different ways of accessing them (and > different abilities) that coming up with a simple interface to represent > them all proved the be a challenge. My thinking on JAPL is that perhaps it would be a good idea for us to develop a few of the 'low hanging fruit' JAPL peripherals so that we can demonstrate to people how they work. Then maybe we can try to bring some companies like Ajile, Dallas Semiconductor, etc. together (kind of like the JCP does) so that these interfaces can be hammered out at a company level. I think that perhaps companies would be more willing to support JAPL in their APIs if they actually participated in their development. Aside from this, over the weekend I will try to download the materials you submitted and take a look at them. Ted __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ |
|
From: Brill P. <bri...@ro...> - 2003-03-05 21:18:18
|
Well done ;) good to see things progressing! I've added an ant build file in /embedlets/japl that will check out and allow you to build the current JAPL/Cork implementation. you obviously need ant installed and working properly. change to the /embedlets/japl dir and execute "ant all". it will check out 3 source trees for you -- cork, platform-tini, platform-jstamp ... once done you can build all three by entering their directory, and running the ant tasks, but you must execute the cork dist target before building the other two. This source has *not* been tested to the extent it need testing... this is the first integration of JAPL with cork... and comments/flames are encouraged. The documentation will be updated as well, as I get things rolling. Also, because things are in such flux at the moment, expect it to break your code now and then. I suggest that a target be added to the embedlets source tree for updating the JAPL libs manually, which will prevent the code from breaking unexpectedly. As for JAPL... I went though several iterations, and found the task much more difficult than it may first appear... the structure (javadocs in dist/docs/api after dist target is run) that I have there now came after long deliberation trying to fit the api into the truly abstract nature we're targeting... however it can be improved... the main hurdle is that there are so many devices, with so many different ways of accessing them (and different abilities) that coming up with a simple interface to represent them all proved the be a challenge. - Brill Pappin Rogue Robotics www.roguerobotics.com ----- Original Message ----- From: "Andrzej Jan Taramina" <an...@ch...> To: <emb...@li...> Sent: Sunday, March 02, 2003 10:25 PM Subject: [Embedlets-dev] I am happy to report.... > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > _______________________________________________ > > ...that the Outpost Container, running the Outhouse sample application > (embedlet/adapter event pipeline) is now running successfully on a TINI > platform. > > Finally got FTP and Telnet working to the TINI that Ted had sent me (thanks > Ted...fun toy!). Turned out there was a conflict with some PGP VPN software > and the TINI. Soon as I disabled the PGPvnet transport protocol, everything > worked fine and I could upload the executable to the TINI. It ran the first > time. Amazing! > > So now we have confirmed reports that the Outpost Embedlet container runs on > the following platforms: > > 1) Windows > 2) Linux > 3) aJile (Systronix JStamp and SaJe boards) > 4) TINI > > Not a bad piece of work over the course of the weekend, if I do say so > myself. > > Though why James hasn't got it running on uVM already, I'll never know. > <grins> > > Got a bit more functionality I want to put in and then I'll post the next > version so that everyone else can play on their own JStamps or TINI's and can > start writing some Embedlets too. > > Looking forward to some feedback too..... > > > Andrzej Jan Taramina > Chaeron Corporation: Enterprise System Solutions > http://www.chaeron.com > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Embedlets-developer mailing list > Emb...@li... > https://lists.sourceforge.net/lists/listinfo/embedlets-developer > |
|
From: Andrzej J. T. <an...@ch...> - 2003-03-05 16:12:34
|
> There is only one 'super-man' token in the world. You've been hogging it > for the last few weeks.. time to give it back!! OK....next week someone else can have the token. I start a new gig in Connetticut next week, so will only have limited weekends/evenings for Embedlets for a while (which is why I was trying to get so much done over the past few weeks). > Well done on the framework. You are spot-on with the splitting into > lightweight interfaces as that is exactly how I will implement this > container. Ie Implementing the container in assembler. Figured that would be the case. > I am busy chewing into a new software contract but have a few tricks up my > sleeve for uVM coming up soon ;-) Excellent.....be interesting to see what you come up with. Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Andrzej J. T. <an...@ch...> - 2003-03-05 16:12:30
|
Ted expresses shock: > You know, I am totally shocked too and I have been having a difficult time > coming up with an explanation for it! I have finally concluded that 'Andrzej' > is a front name for a small group of extraterrestrials who were sent to earth > in order to pass on advanced technologies. Its the only reasonable > explanation that I can think of... ;-) Resistance is futile! You will be embedletted! All your embedlets are belong to us! Oh....and the answer is 42! .....Zaphod |
|
From: Andrzej J. T. <an...@ch...> - 2003-03-05 16:12:26
|
Chris suggests: > It would be interesting to see what performance you are getting on the > event queue with the three platforms. The parameter to measure would be > the producer-event-consumer cycle and then we could calculate the > potential number of events per second. An excellent suggestion. I'll see if I can cobble up a quick benchmark scenario in a day or two, and will post the results soon as I have some. Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Ted K. <tk...@ya...> - 2003-03-04 19:11:38
|
Nicola said: > Let me add that I have not yet said anything because I'm totally shocked > =8-) You know, I am totally shocked too and I have been having a difficult time coming up with an explanation for it! I have finally concluded that 'Andrzej' is a front name for a small group of extraterrestrials who were sent to earth in order to pass on advanced technologies. Its the only reasonable explanation that I can think of... ;-) Ted __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ |
|
From: James C. <ca...@vi...> - 2003-03-04 18:58:35
|
>Though why James hasn't got it running on uVM already, I'll never know. <grins> There is only one 'super-man' token in the world. You've been hogging it for the last few weeks.. time to give it back!! Well done on the framework. You are spot-on with the splitting into lightweight interfaces as that is exactly how I will implement this container. Ie Implementing the container in assembler. I am busy chewing into a new software contract but have a few tricks up my sleeve for uVM coming up soon ;-) James Caska www.muvium.com uVM - 'Java Bred for Embedded' -----Original Message----- From: emb...@li... [mailto:emb...@li...] On Behalf Of Andrzej Jan Taramina Sent: Monday, 3 March 2003 2:25 PM To: emb...@li... Subject: [Embedlets-dev] I am happy to report.... Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] _______________________________________________ ...that the Outpost Container, running the Outhouse sample application (embedlet/adapter event pipeline) is now running successfully on a TINI platform. Finally got FTP and Telnet working to the TINI that Ted had sent me (thanks Ted...fun toy!). Turned out there was a conflict with some PGP VPN software and the TINI. Soon as I disabled the PGPvnet transport protocol, everything worked fine and I could upload the executable to the TINI. It ran the first time. Amazing! So now we have confirmed reports that the Outpost Embedlet container runs on the following platforms: 1) Windows 2) Linux 3) aJile (Systronix JStamp and SaJe boards) 4) TINI Not a bad piece of work over the course of the weekend, if I do say so myself. Though why James hasn't got it running on uVM already, I'll never know. <grins> Got a bit more functionality I want to put in and then I'll post the next version so that everyone else can play on their own JStamps or TINI's and can start writing some Embedlets too. Looking forward to some feedback too..... Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Embedlets-developer mailing list Emb...@li... https://lists.sourceforge.net/lists/listinfo/embedlets-developer |
|
From: Nicola K. B. <nic...@ap...> - 2003-03-04 07:57:12
|
Christopher Smith wrote, On 03/03/2003 19.04:
> _______________________________________________
>
> Andrzej,
>
> Very nice job!
>
> Your coding style, ANT builds and JUnit tests set a very solid and
> professional standard for the project.
>
> This is a great launching pad for the whole endeavor, with a functional mini
> rocket to boot!
Let me add that I have not yet said anything because I'm totally shocked
=8-)
My sincere compliments, I can't wait to play with it!!! :-D
--
Nicola Ken Barozzi nic...@ap...
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
|
|
From: Christopher S. <cs...@oo...> - 2003-03-04 02:02:06
|
Andrzej, It would be interesting to see what performance you are getting on the event queue with the three platforms. The parameter to measure would be the producer-event-consumer cycle and then we could calculate the potential number of events per second. > > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > _______________________________________________ > > ...that the Outpost Container, running the Outhouse sample application > (embedlet/adapter event pipeline) is now running successfully on a TINI > platform. > > Finally got FTP and Telnet working to the TINI that Ted had sent > me (thanks > Ted...fun toy!). Turned out there was a conflict with some PGP > VPN software > and the TINI. Soon as I disabled the PGPvnet transport protocol, > everything > worked fine and I could upload the executable to the TINI. It > ran the first > time. Amazing! > > So now we have confirmed reports that the Outpost Embedlet > container runs on > the following platforms: > > 1) Windows > 2) Linux > 3) aJile (Systronix JStamp and SaJe boards) > 4) TINI > > Not a bad piece of work over the course of the weekend, if I do say so > myself. > > Though why James hasn't got it running on uVM already, I'll never know. > <grins> > > Got a bit more functionality I want to put in and then I'll post the next > version so that everyone else can play on their own JStamps or > TINI's and can > start writing some Embedlets too. > > Looking forward to some feedback too..... > > > Andrzej Jan Taramina > Chaeron Corporation: Enterprise System Solutions > http://www.chaeron.com > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Embedlets-developer mailing list > Emb...@li... > https://lists.sourceforge.net/lists/listinfo/embedlets-developer > |
11 messages has been excluded from this view by a project administrator.
Thanks for helping keep SourceForge clean.
X