October 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Issue 14160: Introduce isXXX dialect testing methods to SmalltalkImage to ease cross-dialect development

by stepharo

Hi jan Thanks for the proposal. I thought about it and I'm against because it goes again the idea of dispatch. I prefer to have a class and some dispatch. Seaside with Grease is the way to go from my perspective. Finally I do not want such methods in the systems because I spent my time removing isXXXX because of bad design. Let us see what other people think. Stef On 4/10/14 22:14, Jan Vrany wrote: > Hi guys, > > I've just opened: > > https://pharo.fogbugz.com/f/cases/14160/Introduce-isXXX-dialect-testing-met… > > Introduce isXXX (isPharo, isVisualWorks, ...) dialect testing methods to > SmalltalkImage to ease multi-dialect development. > > RATIONALE: > > Commonly used approach to solve differences among dialect is to use a > sort of platform object and dispatch there for troublesome operations > that has to be specialized. This platform object is usually in platform > specific package. > Other option is to load some library like Grease or Sport. > > The problem of the first approach is that brings to much (unnecessary) > burden when used for two, three things. The amount of of the code and > management is way to bigger then the amount of the code that has to be > specialized. Loading Grease/Sport on the other hand introduces a > dependency on an external package - not worth of for two or three > things. > > The proposed dialect testing messages would allow for simple, > #ifdef-like idiom like: > > | stream | > ... > ((Smalltalk respondsTo: #isSomeCoolDialect) and:[Smalltalk > isSomeCoolDialect]) ifTrue:[ > stream := CharacterWriteStream on: (String new: 10) > ] ifFalse:[ > stream := WriteStream on: (String new: 10) > ] > > The #respondsTo: check, while not nice, is required as at the moment not > all dialects could be trusted to have these testing messages. > > Putting these methods may not stick with Pharo standard (whatever it > is), but Smalltalk global is probably one of the > very few that are present in pretty much every Smalltalk implementation. > Other option would be to place them to the class side of an Object > (which is amost certainly present everywhere), however > > Smalltalk isPharo > > reads better than > > Object isPharo. > > Best, Jan > > >

Oct. 5, 2014

Re: [Pharo-dev] Athens and TxText Re: About ways to participate in community and general negativity

by stepharo

Thanks this is a great initiative. On 4/10/14 22:21, Nicolai Hess wrote: > > 2014-10-04 12:11 GMT+02:00 stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>>: > > > What are the plans to integrate TxText? > > > - Igor is taking clients one by one and improving txText. We > got a new syntax hilighter. > - Then I want to replace the workspace by a TxWorkspace. > - After for athens we should rewrite all the drawOn: methods. > - We were waiting to get integration based on configurations > to include it and now this is ready. > so soon we will have > - TxText inside Pharo > - > > > > I made a fogbugz issue about changes to be done for > athens based morphic drawing > > 13790 <https://pharo.fogbugz.com/default.asp?13790> > Port what is needed for Athens (drawing morphs) > > One is about TextMorphs, I wrote about what I had to change to make > the basic drawing working. Maybe some of it is useless with TxText > but maybe it helps. > > 13449 <https://pharo.fogbugz.com/default.asp?13449> > AthensWrapMorph can not draw TextMorphs > > If we don't port/rewrite all text based morphs, we will have an > issue with this: > > 13448 <https://pharo.fogbugz.com/default.asp?13448> > No Font emphasis (bold/oblique...) on text drawn with Athens > > > AFAIK for the font handling in text morphs, they use the "normal" font > and holds the emphasis property on their own. But Athens (FreeType > renderer) > relies on the font allone, that means if you want a bold font you > don't take > the normal font *name* + bold emphasis, but you'll have to take the > "bold font" FreeType font entry, or something like that. > > About changing all the drawOn: methods for athens, there is > an alternative I proposed in > 13866 <https://pharo.fogbugz.com/default.asp?13866> > AthensFormCanvasWrapper > > Font rendering bug: > The font-bug for FreeType fonts (wrong sized characters) in Athens is > not solved. > (see screenshot) > The current solution is: "Don't use the same font (+font size) for > Athens and > Morphic". > (http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2014-June/097128…) > But of course, how can we enforce this? > > > > > Now I know that GTools have been used in Moose for a long > time, but its integration to Pharo REPLACING Workspace has > been a cultural shock to those that haven't used it before > (myself included, though I'm lookign forward to adapting). I > think there'll be similar culture shock when Pharo 4 is > released, from those that don't follow the bleeding edge. I'd > strongly suggest that GTools operate for ONE release alongside > existing tools, as an additional item in the first level World > menu next to 'Workspace'. > > I said the same to doru :). > > > Indeed, even if Playground is quite stable through long use in > Moose, it is new to Pharo, and marking its menu entry as > 'Experimental' for now might provide some benefits. > > * This may provide a to stress test new evolving frameworks > like TxText & Rubric - without affecting existing tools. > > * Now Playground has a wider community exposure, feedback from > new users is likely to be less pressure and less negative if > they still have access to old tools. > > * Feedback may result in changes. > > * Reduced culture shock. Builds confidence in a stable system > not going "too fast" but just "fast enough" (very subjective I > know). > > > >

Oct. 5, 2014

Re: [Pharo-dev] GT first impressions

by stepharo

On 4/10/14 22:43, Tudor Girba wrote: > Hi HernÃ¡n, > > Thanks for the feedback. Just a question: Was there anything you do > like? :) > > The rest of the reply is inline. > > > On Sat, Oct 4, 2014 at 10:10 PM, HernÃ¡n Morales Durand > <hernan.morales(a)gmail.com <mailto:hernan.morales@gmail.com>> wrote: > > Sorry if following issues were reported. I have seen so many mails > about GT that I wanted to try it. These are my first notes and > personal tastes, don't take them as negative just want to provide > some feedback: > > - First weird thing: The Workspace doesn't open a Workspace > anymore, it opens a Playground window. > > > That is because it is still a work in progress. > > - When I select code, right click gives no "Copy, Cut, Delete" > commands. > > > This was reported. The menu is missing on purpose. I still have a hard > time understanding why a developer needs those menu entries, but we > will add them back. Btw, the shortcuts do work. Doru can you add sender and implementors because I saw that newbies are really lost when the cannot know what they can do. > - Selecting an instance variable from the "State" tab, completely > shift the code view and scrolls to a new Inspector. Is not that I > would love to scroll back everytime to get a view on my code. > > > The usage depends on the scenario in which you are. In most cases, > when you do want to drill through many objects, you are likely to only > use the playground as an entry point. When you build a more elaborate > piece of code in the playground, you typically do not need to drill > too much. In any case, if you want to scroll back, there are also > keybindings that allow you to navigate: Cmd+Alt+Left/Right. > > - I cannot find how to close new Inspector tabs. > > > This is a feature that is already planned. > > - "Print it" seems broken. It seems to print evaluation result but > suddenly dissapears. > > > What do you mean? Can you elaborate on that? Print it should behave > like here: > > - Debugger buttons Into, Through, etc. > > -- They are too small and close themselves for the importance they > have. > -- They have no caption, so you have to mouse over to know what > they do (until you get used to) > -- They are like "too distant" from the code view. > > > The debugger is not in the Pharo image, so I think you are trying the > Moose image. Is that so? > In any case, the positioning of the icons will be the same everywhere > in GT (to the right of the scope they relate to). We are still > fiddling with the right balance in the debugger. putting a caption would be a great point. why forcing people to learn icons. Icons should be there to help not to force learning. > > Cheers, > Doru > > Cheers, > > HernÃ¡n > > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > > "Every thing has its own flow"

Oct. 5, 2014

Re: [Pharo-dev] GT first impressions

by stepharo

On 4/10/14 22:10, HernÃ¡n Morales Durand wrote: > Sorry if following issues were reported. I have seen so many mails > about GT that I wanted to try it. These are my first notes and > personal tastes, don't take them as negative just want to provide some > feedback: > > - First weird thing: The Workspace doesn't open a Workspace anymore, > it opens a Playground window. > - When I select code, right click gives no "Copy, Cut, Delete" commands. > - Selecting an instance variable from the "State" tab, completely > shift the code view and scrolls to a new Inspector. Is not that I > would love to scroll back everytime to get a view on my code. > - I cannot find how to close new Inspector tabs. > - "Print it" seems broken. It seems to print evaluation result but > suddenly dissapears. > - Debugger buttons Into, Through, etc. > -- They are too small and close themselves for the importance they have. > -- They have no caption, so you have to mouse over to know what they > do (until you get used to) > -- They are like "too distant" from the code view. > I already reported most of them on the moose mailing-list :) Tx! > Cheers, > > HernÃ¡n > >

Oct. 5, 2014

Re: [Pharo-dev] Inspector steals my Window !

by Tudor Girba

This is why the Preview should be static. For the Morph preview we simply render the form. Doru On Sun, Oct 5, 2014 at 12:32 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > Inspect in playground ("inspect it" from menu or with the play-icon): > > |t| > t:=TextModel new. > t title:'Test'. > t openWithSpec > > It opens a window with the textfield and an inspector. > In the inspector, choose the "preview" tab, your textfield window > will dissapear from the world and only show up in the preview tab. > > Funny! > But is there any way to get the window back to the world? > > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 5, 2014

Re: [Pharo-dev] GT first impressions

by Tudor Girba

Oh, I see now. Where was the fix committed? Doru On Sun, Oct 5, 2014 at 12:02 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > 2014-10-04 23:13 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > >> Hi, >> >> On Sat, Oct 4, 2014 at 11:02 PM, HernÃ¡n Morales Durand < >> hernan.morales(a)gmail.com> wrote: >> >>> Hi Doru >>> >>> 2014-10-04 17:43 GMT-03:00 Tudor Girba <tudor(a)tudorgirba.com>: >>> >>>> Hi HernÃ¡n, >>>> >>>> Thanks for the feedback. Just a question: Was there anything you do >>>> like? :) >>>> >>>> >>> One day I will write about what I like, I promise! >>> >> >> Good :) >> >> >>> [...] >>>> >>>>> - When I select code, right click gives no "Copy, Cut, Delete" >>>>> commands. >>>>> >>>> >>>> This was reported. The menu is missing on purpose. I still have a hard >>>> time understanding why a developer needs those menu entries, but we will >>>> add them back. Btw, the shortcuts do work. >>>> >>> >>> In my case, because sometimes I do remote desktop over remote desktop >>> over Windows and Linux, and protocols use to lost dead keys like Ctrl, >>> Shift, etc. >>> >> >> Ok. That makes sense. Andrei added these actions in the latest >> development version. Loading again like you said below should provide you >> those actions. >> >> [...] >> >>> >>>>> - "Print it" seems broken. It seems to print evaluation result but >>>>> suddenly dissapears. >>>>> >>>> >>>> What do you mean? Can you elaborate on that? Print it should behave >>>> like here: >>>> >>>> >>> >>> I just typed >>> >>> DateAndTime now asTime. >>> >>> and "Print it" displays current date and time but get quickly refreshed. >>> This happens only the first time, print it again didn't show any results at >>> all. Let me know if you cannot reproduce, below is how I installed GT. >>> >> >> I cannot reproduce it. Print it should popup the result and the popup >> should remain until you either press Esc or you change focus to something >> else. >> > > This happens on choosing "PrintIt" from the menu. > There is an issue on fogbugz > 14128 <https://pharo.fogbugz.com/default.asp?14128> > "Print it" from Playground menu does not work > > already fixed an integrated in 40276 > > > > >> >> It should look like this: >> http://www.humane-assessment.com/blog/rethinking-print-it-in-pharo/ >> >> >>> >>> >>>> - Debugger buttons Into, Through, etc. >>>>> >>>> -- They are too small and close themselves for the importance they have. >>>>> -- They have no caption, so you have to mouse over to know what they >>>>> do (until you get used to) >>>>> -- They are like "too distant" from the code view. >>>>> >>>> >>>> The debugger is not in the Pharo image, so I think you are trying the >>>> Moose image. Is that so? >>>> >>> >>> I am trying in a fresh Pharo 3.0 image on Windows 8.1, and followed >>> instructions in >>> http://www.humane-assessment.com/blog/installing-gtoolkit .BTW when the >>> installation finish the image seems to automatically closes, but this is >>> reported in other recent post. >>> >> >> Indeed, the script should have mention "activateWithoutSaving" instead of >> "activate". >> >> >> Cheers, >> Doru >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> > > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 5, 2014

Inspector steals my Window !

by Nicolai Hess

Inspect in playground ("inspect it" from menu or with the play-icon): |t| t:=TextModel new. t title:'Test'. t openWithSpec It opens a window with the textfield and an inspector. In the inspector, choose the "preview" tab, your textfield window will dissapear from the world and only show up in the preview tab. Funny! But is there any way to get the window back to the world?

Oct. 4, 2014

Re: [Pharo-dev] GT first impressions

by Nicolai Hess

2014-10-04 23:13 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > On Sat, Oct 4, 2014 at 11:02 PM, HernÃ¡n Morales Durand < > hernan.morales(a)gmail.com> wrote: > >> Hi Doru >> >> 2014-10-04 17:43 GMT-03:00 Tudor Girba <tudor(a)tudorgirba.com>: >> >>> Hi HernÃ¡n, >>> >>> Thanks for the feedback. Just a question: Was there anything you do >>> like? :) >>> >>> >> One day I will write about what I like, I promise! >> > > Good :) > > >> [...] >>> >>>> - When I select code, right click gives no "Copy, Cut, Delete" commands. >>>> >>> >>> This was reported. The menu is missing on purpose. I still have a hard >>> time understanding why a developer needs those menu entries, but we will >>> add them back. Btw, the shortcuts do work. >>> >> >> In my case, because sometimes I do remote desktop over remote desktop >> over Windows and Linux, and protocols use to lost dead keys like Ctrl, >> Shift, etc. >> > > Ok. That makes sense. Andrei added these actions in the latest development > version. Loading again like you said below should provide you those actions. > > [...] > >> >>>> - "Print it" seems broken. It seems to print evaluation result but >>>> suddenly dissapears. >>>> >>> >>> What do you mean? Can you elaborate on that? Print it should behave like >>> here: >>> >>> >> >> I just typed >> >> DateAndTime now asTime. >> >> and "Print it" displays current date and time but get quickly refreshed. >> This happens only the first time, print it again didn't show any results at >> all. Let me know if you cannot reproduce, below is how I installed GT. >> > > I cannot reproduce it. Print it should popup the result and the popup > should remain until you either press Esc or you change focus to something > else. > This happens on choosing "PrintIt" from the menu. There is an issue on fogbugz 14128 <https://pharo.fogbugz.com/default.asp?14128> "Print it" from Playground menu does not work already fixed an integrated in 40276 > > It should look like this: > http://www.humane-assessment.com/blog/rethinking-print-it-in-pharo/ > > >> >> >>> - Debugger buttons Into, Through, etc. >>>> >>> -- They are too small and close themselves for the importance they have. >>>> -- They have no caption, so you have to mouse over to know what they do >>>> (until you get used to) >>>> -- They are like "too distant" from the code view. >>>> >>> >>> The debugger is not in the Pharo image, so I think you are trying the >>> Moose image. Is that so? >>> >> >> I am trying in a fresh Pharo 3.0 image on Windows 8.1, and followed >> instructions in http://www.humane-assessment.com/blog/installing-gtoolkit >> .BTW when the installation finish the image seems to automatically closes, >> but this is reported in other recent post. >> > > Indeed, the script should have mention "activateWithoutSaving" instead of > "activate". > > > Cheers, > Doru > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

Oct. 4, 2014

Re: [Pharo-dev] About ways to participate in community and general negativity

by Tudor Girba

Hi Thierry, On Sat, Oct 4, 2014 at 11:32 PM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > Hi Doru, > > Le 04/10/2014 22:48, Tudor Girba a Ã©crit : > >> Hi Thierry, >> >> On Sat, Oct 4, 2014 at 6:49 PM, Thierry Goubier >> <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: >> >> Hi, >> >> Le 04/10/2014 11:54, Tudor Girba a Ã©crit : >> >> And now you are starting to have the issue of handling >> slices on GT >> from Pharo: do people have to register on Moose, >> resynchronize on GT >> on Moose, push their slices there, wait for Moose to push a >> slice to >> integrate on Pharo, wait for Pharo to integrate that slice? >> >> >> Something like that. Only there is no wait time to integrate in >> Moose as >> GT is a standalone project, and Moose simply integrates the latest >> development version of all its dependencies. So, there is not >> that much >> difference to integrating in Pharo. Once a new stable version of >> GT is >> available, it will automatically be available in Pharo. >> >> >> I don't think this is the way to go. It raises an additional barrier >> to contributions to GT, such as: >> >> A - I tried GTPlayground on Pharo, I had a DNU, here is the issue I >> created. >> >> A - I pushed a slice with the corrections >> >> B - In GT development version we decided to go another way. We don't >> need your slice. Please wait for the next stable version and try >> again. Thank you for your contribution. >> >> A --- >> >> I'm not sure you'll get another contribution from A after that >> exchange ;) >> >> >> I do not understand your scenario. How is it any different from the >> Pharo integration? If the integrator decides it's not a good fix, it >> does not get integrated. There will be barely any delay. >> > > I think you need to reread the exchange. Because Glamour main development > is kept separate from Pharo, with a Glamour stable being pushed into Pharo, > then you increase the chances that you diverges temporarily the stable > Glamour from the one in Pharo. And simply make it costly for someone in > Pharo to participate. > > I don't think it would cost you much to consider that stable Glamour is > the one in Pharo, and that the development one is kept in Moose, with > merges of the development Glamour to the stable one in Pharo. You would > loose a bit of control on stable Glamour, because any maintainer of Pharo > could integrate fixes, in exchange for making it easier for non-Moose users > to contribute. Your call :) You should take into account that with Pharo we are moving towards configurations. That is why Glamour and GT will remain as separate projects loaded via configurations. I actually do not mind more people making decisions. In fact, the Moose development doesn't happen through an inbox, but by directly committing. And we work with the latest development version, not the stable one. We started with the stable one in Pharo to smoothen the integration. It will take a bit of time to find a rhythm that works, but I definitely think this is the right direction. > I found that stepping through the opening sequence of GT to >> debug >> MorphTreeMorph a pain and had to find another way to >> understand the >> issue. >> >> Can you be more specific? What did you try to achieve and did >> not manage? >> >> >> I was trying to find out why a MorphTreeMorph would DNU upon >> GTDebugger opening ;) >> >> I gave up and went blindly into the MorphTreeMorph code instead, >> trying to solve it by luck. >> >> >> Can you be more specific, please? What did you do to get a DNU? >> > > That was at that occasion: http://moose-dev.97923.n3. > nabble.com/debugger-in-the-last-moose-tp4032413p4032415.html Oh. I remember :). I thought you encountered a more recent bug. > > >> I do have specific tools I can use in such circumstances >> that you >> don't have. >> >> >> What kind of tools? I would be interested in learning about them >> and the >> analysis use cases they support. >> >> >> I have a trace tool for those situations (and also for parser work). >> >> >> What trace tool? Is an example available? >> > > http://lists.gforge.inria.fr/pipermail/pharo-project/2012-July/067679.html > > My original use case was: >> - Finding the bug in an error correction decoding algorithm which >> worked without error, but with non-satisfying results: lower than >> expected SNR. >> - Has then been used very successfully to explain the algorithm. >> - Was then used as the basis for a hardware design methodology by >> dynamic code traces of multithreaded programs >> >> Other use cases I use it for: >> - Debugging code in Morphic (rectangles, MorphTreeMorph stuff, text >> editor errors) where halt makes the image unusable. >> - Debugging code in Parsers when the code of a reduction is not >> working properly (somewhere deep in the AST). >> >> >> Is this more than a logger? >> > > Part of it is a logger, to record events. > > A second part of it is a code rewriting tool. You give it a method, it > adds the code to trace the execution and recompiles the method. > > A third part is a viewer which links each recorded event with the > expression which generated it in the method. > > (The second part could be changed to use the Opal facilities instead of > code rewriting. There is probably work to be done on the logger as well: > remote logging via RS232, Jtag probes, etc...). Sounds interesting. I never looked at it. Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"

Oct. 4, 2014

Re: [Pharo-dev] About ways to participate in community and general negativity

by Thierry Goubier

Hi Doru, Le 04/10/2014 22:48, Tudor Girba a Ã©crit : > Hi Thierry, > > On Sat, Oct 4, 2014 at 6:49 PM, Thierry Goubier > <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: > > Hi, > > Le 04/10/2014 11:54, Tudor Girba a Ã©crit : > > And now you are starting to have the issue of handling > slices on GT > from Pharo: do people have to register on Moose, > resynchronize on GT > on Moose, push their slices there, wait for Moose to push a > slice to > integrate on Pharo, wait for Pharo to integrate that slice? > > > Something like that. Only there is no wait time to integrate in > Moose as > GT is a standalone project, and Moose simply integrates the latest > development version of all its dependencies. So, there is not > that much > difference to integrating in Pharo. Once a new stable version of > GT is > available, it will automatically be available in Pharo. > > > I don't think this is the way to go. It raises an additional barrier > to contributions to GT, such as: > > A - I tried GTPlayground on Pharo, I had a DNU, here is the issue I > created. > > A - I pushed a slice with the corrections > > B - In GT development version we decided to go another way. We don't > need your slice. Please wait for the next stable version and try > again. Thank you for your contribution. > > A --- > > I'm not sure you'll get another contribution from A after that > exchange ;) > > > I do not understand your scenario. How is it any different from the > Pharo integration? If the integrator decides it's not a good fix, it > does not get integrated. There will be barely any delay. I think you need to reread the exchange. Because Glamour main development is kept separate from Pharo, with a Glamour stable being pushed into Pharo, then you increase the chances that you diverges temporarily the stable Glamour from the one in Pharo. And simply make it costly for someone in Pharo to participate. I don't think it would cost you much to consider that stable Glamour is the one in Pharo, and that the development one is kept in Moose, with merges of the development Glamour to the stable one in Pharo. You would loose a bit of control on stable Glamour, because any maintainer of Pharo could integrate fixes, in exchange for making it easier for non-Moose users to contribute. Your call :) > I found that stepping through the opening sequence of GT to > debug > MorphTreeMorph a pain and had to find another way to > understand the > issue. > > Can you be more specific? What did you try to achieve and did > not manage? > > > I was trying to find out why a MorphTreeMorph would DNU upon > GTDebugger opening ;) > > I gave up and went blindly into the MorphTreeMorph code instead, > trying to solve it by luck. > > > Can you be more specific, please? What did you do to get a DNU? That was at that occasion: http://moose-dev.97923.n3.nabble.com/debugger-in-the-last-moose-tp4032413p4… > > I do have specific tools I can use in such circumstances > that you > don't have. > > > What kind of tools? I would be interested in learning about them > and the > analysis use cases they support. > > > I have a trace tool for those situations (and also for parser work). > > > What trace tool? Is an example available? http://lists.gforge.inria.fr/pipermail/pharo-project/2012-July/067679.html > My original use case was: > - Finding the bug in an error correction decoding algorithm which > worked without error, but with non-satisfying results: lower than > expected SNR. > - Has then been used very successfully to explain the algorithm. > - Was then used as the basis for a hardware design methodology by > dynamic code traces of multithreaded programs > > Other use cases I use it for: > - Debugging code in Morphic (rectangles, MorphTreeMorph stuff, text > editor errors) where halt makes the image unusable. > - Debugging code in Parsers when the code of a reduction is not > working properly (somewhere deep in the AST). > > > Is this more than a logger? Part of it is a logger, to record events. A second part of it is a code rewriting tool. You give it a method, it adds the code to trace the execution and recompiles the method. A third part is a viewer which links each recorded event with the expression which generated it in the method. (The second part could be changed to use the Opal facilities instead of code rewriting. There is probably work to be done on the logger as well: remote logging via RS232, Jtag probes, etc...). Thierry

Oct. 4, 2014