Roassal Camp Smalltalk
Locked
 
|
Dear Colleagues and Friends,
We are happy to announce we will organize a CampSmalltalk about the Roassal visualization engine, on _Sunday 12 July_. As far as we have seen, the interests are multiple. Here is a list of topics we will happy to work on: - Port of Roassal on VisualWorks - Using Roassal on Gemstone - HTML/JavaScript export - Improving Grapher, our charting library If you wish to participate, get in touch with us. Since we will probably have a sponsoring of the event, it would be nice to know how many will attend to ease the logistic and the pizza ordering :-) Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
|
|
Hi Alex, is it possible to add some discussion about stuff we did in roassal for dynacase to the list? Because I feel there is some duplication effort and also we could probably contribute some stuff we did back. Or perhaps even more general discussion about using roassal for more dynamic and modifiable visualizations/modeling (e.g. composite shapes, bendable lines, resizable boxes, etc.) Peter On Thu, Jun 4, 2015 at 7:55 PM, Alexandre Bergel <[hidden email]> wrote: Dear Colleagues and Friends, |
|
|
In reply to this post by abergel
I’m interested in participating. Personally I’d like to talk more about design decisions behind roassal ecosystem, release strategy and so on. Usually when I work with Roassal I have this issue that things are breaking because of rapid changes, or because of the differences between different parts of roassal. Maybe someone is also concerned about this, so we can discuss and maybe improve something…
Uko > On 04 Jun 2015, at 19:55, Alexandre Bergel <[hidden email]> wrote: > > Dear Colleagues and Friends, > > We are happy to announce we will organize a CampSmalltalk about the Roassal visualization engine, on _Sunday 12 July_. > > As far as we have seen, the interests are multiple. Here is a list of topics we will happy to work on: > - Port of Roassal on VisualWorks > - Using Roassal on Gemstone > - HTML/JavaScript export > - Improving Grapher, our charting library > > If you wish to participate, get in touch with us. Since we will probably have a sponsoring of the event, it would be nice to know how many will attend to ease the logistic and the pizza ordering :-) > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > |
|
|
On Fri, Jun 5, 2015 at 3:29 PM, Yuriy Tymchuk <[hidden email]> wrote: I’m interested in participating. Personally I’d like to talk more about design decisions behind roassal ecosystem, release strategy and so on. Usually when I work with Roassal I have this issue that things are breaking because of rapid changes, or because of the differences between different parts of roassal. Maybe someone is also concerned about this, so we can discuss and maybe improve something… Yes I am also interested in this, right now I am actually using quite old version (month+) because I didn't have time to keep up. :) (Arguably 90% of my problems were from infamous composite shapes. :)) Peter
|
|
|
But are there numbered version to refer to?
Uko
|
|
|
There sure are, look at ConfigurationOfRoassal2>>version*: and in my baseline I have something like ~~~~~~~~~~~ spec project: 'Roassal2' with: [ spec className: #ConfigurationOfRoassal2; versionString: '1.52'; repository: 'http://smalltalkhub.com/mc/ObjectProfile/Roassal2/main/' ]; ~~~~~~~~~~~ Peter On Fri, Jun 5, 2015 at 4:37 PM, Yuriy Tymchuk <[hidden email]> wrote:
|
|
|
In reply to this post by Uko2
> I’m interested in participating. Personally I’d like to talk more about design decisions behind roassal ecosystem, release strategy and so on. Usually when I work with Roassal I have this issue that things are breaking because of rapid changes, or because of the differences between different parts of roassal. Maybe someone is also concerned about this, so we can discuss and maybe improve something… +1 I coudl also present a bit bloc because Roassal could ported to it :) > > Uko > >> On 04 Jun 2015, at 19:55, Alexandre Bergel <[hidden email]> wrote: >> >> Dear Colleagues and Friends, >> >> We are happy to announce we will organize a CampSmalltalk about the Roassal visualization engine, on _Sunday 12 July_. >> >> As far as we have seen, the interests are multiple. Here is a list of topics we will happy to work on: >> - Port of Roassal on VisualWorks >> - Using Roassal on Gemstone >> - HTML/JavaScript export >> - Improving Grapher, our charting library >> >> If you wish to participate, get in touch with us. Since we will probably have a sponsoring of the event, it would be nice to know how many will attend to ease the logistic and the pizza ordering :-) >> >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> > > |
|
|
In reply to this post by Peter Uhnak
Oh, then it’s my bad. Last time I’ve checked it seemed that it wasn’t updated for a long time. Maybe I was wrong.
Uko
|
|
|
Well at least for me it is certainly not clear what release policy is Roassal following; i.e. if I see a minor version change what to expect, if any BC breaks were introduced, etc. Of course this is extra effort for the person doing it, so it should be taken with care. But there are certainly things to be discussed about this. Peter On Fri, Jun 5, 2015 at 7:31 PM, Yuriy Tymchuk <[hidden email]> wrote:
|
|
|
> Well at least for me it is certainly not clear what release policy is Roassal following; i.e. if I see a minor version change what to expect, if any BC breaks were introduced, etc. Of course this is extra effort for the person doing it, so it should be taken with care. But there are certainly things to be discussed about this.
Hi Peter, Indeed, we have not been good at producing a descent version numbering schema. My position was always this one: the last version should always fit your need. However, some product favored stability when Roassal is used in a commercial setting. We will be more careful when updating the configuration with a proper version number. Cheers, Alexandre > > On Fri, Jun 5, 2015 at 7:31 PM, Yuriy Tymchuk <[hidden email]> wrote: > Oh, then it’s my bad. Last time I’ve checked it seemed that it wasn’t updated for a long time. Maybe I was wrong. > > Uko > > > >> On 05 Jun 2015, at 18:08, Peter Uhnák <[hidden email]> wrote: >> >> There sure are, look at ConfigurationOfRoassal2>>version*: >> >> and in my baseline I have something like >> >> ~~~~~~~~~~~ >> spec >> project: 'Roassal2' with: [ >> spec >> className: #ConfigurationOfRoassal2; >> versionString: '1.52'; >> repository: 'http://smalltalkhub.com/mc/ObjectProfile/Roassal2/main/' ]; >> ~~~~~~~~~~~ >> >> Peter >> >> On Fri, Jun 5, 2015 at 4:37 PM, Yuriy Tymchuk <[hidden email]> wrote: >> But are there numbered version to refer to? >> >> Uko >> >>> On 05 Jun 2015, at 16:34, Peter Uhnák <[hidden email]> wrote: >>> >>> >>> >>> On Fri, Jun 5, 2015 at 3:29 PM, Yuriy Tymchuk <[hidden email]> wrote: >>> I’m interested in participating. Personally I’d like to talk more about design decisions behind roassal ecosystem, release strategy and so on. Usually when I work with Roassal I have this issue that things are breaking because of rapid changes, or because of the differences between different parts of roassal. Maybe someone is also concerned about this, so we can discuss and maybe improve something… >>> >>> Yes I am also interested in this, right now I am actually using quite old version (month+) because I didn't have time to keep up. :) (Arguably 90% of my problems were from infamous composite shapes. :)) >>> >>> Peter >>> >>> Uko >>> >>> > On 04 Jun 2015, at 19:55, Alexandre Bergel <[hidden email]> wrote: >>> > >>> > Dear Colleagues and Friends, >>> > >>> > We are happy to announce we will organize a CampSmalltalk about the Roassal visualization engine, on _Sunday 12 July_. >>> > >>> > As far as we have seen, the interests are multiple. Here is a list of topics we will happy to work on: >>> > - Port of Roassal on VisualWorks >>> > - Using Roassal on Gemstone >>> > - HTML/JavaScript export >>> > - Improving Grapher, our charting library >>> > >>> > If you wish to participate, get in touch with us. Since we will probably have a sponsoring of the event, it would be nice to know how many will attend to ease the logistic and the pizza ordering :-) >>> > >>> > Cheers, >>> > Alexandre >>> > -- >>> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> > Alexandre Bergel http://www.bergel.eu >>> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> > >>> > >>> > >>> > >>> >>> >>> >> >> > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
|
|
> On 08 Jun 2015, at 18:22, Alexandre Bergel <[hidden email]> wrote: > >> Well at least for me it is certainly not clear what release policy is Roassal following; i.e. if I see a minor version change what to expect, if any BC breaks were introduced, etc. Of course this is extra effort for the person doing it, so it should be taken with care. But there are certainly things to be discussed about this. > > Hi Peter, > > Indeed, we have not been good at producing a descent version numbering schema. > My position was always this one: the last version should always fit your need. However, some product favored stability when Roassal is used in a commercial setting. > We will be more careful when updating the configuration with a proper version number. Versioning is in fact a complex thing. That’s why I suggest to have a brainstorming session during the camp. Uko > > Cheers, > Alexandre > > >> >> On Fri, Jun 5, 2015 at 7:31 PM, Yuriy Tymchuk <[hidden email]> wrote: >> Oh, then it’s my bad. Last time I’ve checked it seemed that it wasn’t updated for a long time. Maybe I was wrong. >> >> Uko >> >> >> >>> On 05 Jun 2015, at 18:08, Peter Uhnák <[hidden email]> wrote: >>> >>> There sure are, look at ConfigurationOfRoassal2>>version*: >>> >>> and in my baseline I have something like >>> >>> ~~~~~~~~~~~ >>> spec >>> project: 'Roassal2' with: [ >>> spec >>> className: #ConfigurationOfRoassal2; >>> versionString: '1.52'; >>> repository: 'http://smalltalkhub.com/mc/ObjectProfile/Roassal2/main/' ]; >>> ~~~~~~~~~~~ >>> >>> Peter >>> >>> On Fri, Jun 5, 2015 at 4:37 PM, Yuriy Tymchuk <[hidden email]> wrote: >>> But are there numbered version to refer to? >>> >>> Uko >>> >>>> On 05 Jun 2015, at 16:34, Peter Uhnák <[hidden email]> wrote: >>>> >>>> >>>> >>>> On Fri, Jun 5, 2015 at 3:29 PM, Yuriy Tymchuk <[hidden email]> wrote: >>>> I’m interested in participating. Personally I’d like to talk more about design decisions behind roassal ecosystem, release strategy and so on. Usually when I work with Roassal I have this issue that things are breaking because of rapid changes, or because of the differences between different parts of roassal. Maybe someone is also concerned about this, so we can discuss and maybe improve something… >>>> >>>> Yes I am also interested in this, right now I am actually using quite old version (month+) because I didn't have time to keep up. :) (Arguably 90% of my problems were from infamous composite shapes. :)) >>>> >>>> Peter >>>> >>>> Uko >>>> >>>>> On 04 Jun 2015, at 19:55, Alexandre Bergel <[hidden email]> wrote: >>>>> >>>>> Dear Colleagues and Friends, >>>>> >>>>> We are happy to announce we will organize a CampSmalltalk about the Roassal visualization engine, on _Sunday 12 July_. >>>>> >>>>> As far as we have seen, the interests are multiple. Here is a list of topics we will happy to work on: >>>>> - Port of Roassal on VisualWorks >>>>> - Using Roassal on Gemstone >>>>> - HTML/JavaScript export >>>>> - Improving Grapher, our charting library >>>>> >>>>> If you wish to participate, get in touch with us. Since we will probably have a sponsoring of the event, it would be nice to know how many will attend to ease the logistic and the pizza ordering :-) >>>>> >>>>> Cheers, >>>>> Alexandre >>>>> -- >>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>> Alexandre Bergel http://www.bergel.eu >>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >> >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > |
|
|
Since I've already run into second thing in agile visualization book that is outdated (RTArrow, which was some time ago renamed to RTArrowedLine (https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/Roassal/0104-Roassal.html section 2.2) it made me wonder how many things like these are there (considering in neither case I was looking for errors). So, maybe this could be also addressed at the camp if there will be time? Writing is hard and reviewing own work is exercise in futility (I see things that I want to see, not what is there). Some of it (like the examples) could be even executed to verify their validity. And lastly what I saw in another thread (by stef) - graceful deprecation, and stabilization of API. Peter On Tue, Jun 9, 2015 at 9:57 PM, Yuriy Tymchuk <[hidden email]> wrote:
|
|
|
Hi Peter
Definitively. Having stable API is key for us and for everybody. For us (synectique), we stop to change versions around 6 months ago. This is sad that we have to shield us from Roassal but this is what we are doing. We cannot fight to get clients and change all the time our code. As you see, I'm the only one to say it because usman already reported this problem one year ago and we discussed with alex but we faced the same problem and now he stopped even to report problems. So we will rediscuss in july when alex is visiting us and else we will stay with an old version. The problem is that the community around roassal will not benefit from this but we cannot do much. Stef
|
|
|
In reply to this post by Peter Uhnak
Hi Peter,
I am really sorry about the instability. The book chapter has been updated. Cheers, Alexandre > On Jun 14, 2015, at 7:10 PM, Peter Uhnák <[hidden email]> wrote: > > Since I've already run into second thing in agile visualization book that is outdated (RTArrow, which was some time ago renamed to RTArrowedLine (https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/Roassal/0104-Roassal.html section 2.2) it made me wonder how many things like these are there (considering in neither case I was looking for errors). > > So, maybe this could be also addressed at the camp if there will be time? > > Writing is hard and reviewing own work is exercise in futility (I see things that I want to see, not what is there). Some of it (like the examples) could be even executed to verify their validity. > > And lastly what I saw in another thread (by stef) - graceful deprecation, and stabilization of API. > > Peter > > On Tue, Jun 9, 2015 at 9:57 PM, Yuriy Tymchuk <[hidden email]> wrote: > > > On 08 Jun 2015, at 18:22, Alexandre Bergel <[hidden email]> wrote: > > > >> Well at least for me it is certainly not clear what release policy is Roassal following; i.e. if I see a minor version change what to expect, if any BC breaks were introduced, etc. Of course this is extra effort for the person doing it, so it should be taken with care. But there are certainly things to be discussed about this. > > > > Hi Peter, > > > > Indeed, we have not been good at producing a descent version numbering schema. > > My position was always this one: the last version should always fit your need. However, some product favored stability when Roassal is used in a commercial setting. > > We will be more careful when updating the configuration with a proper version number. > > Versioning is in fact a complex thing. That’s why I suggest to have a brainstorming session during the camp. > > Uko > > > > > Cheers, > > Alexandre > > > > > >> > >> On Fri, Jun 5, 2015 at 7:31 PM, Yuriy Tymchuk <[hidden email]> wrote: > >> Oh, then it’s my bad. Last time I’ve checked it seemed that it wasn’t updated for a long time. Maybe I was wrong. > >> > >> Uko > >> > >> > >> > >>> On 05 Jun 2015, at 18:08, Peter Uhnák <[hidden email]> wrote: > >>> > >>> There sure are, look at ConfigurationOfRoassal2>>version*: > >>> > >>> and in my baseline I have something like > >>> > >>> ~~~~~~~~~~~ > >>> spec > >>> project: 'Roassal2' with: [ > >>> spec > >>> className: #ConfigurationOfRoassal2; > >>> versionString: '1.52'; > >>> repository: 'http://smalltalkhub.com/mc/ObjectProfile/Roassal2/main/' ]; > >>> ~~~~~~~~~~~ > >>> > >>> Peter > >>> > >>> On Fri, Jun 5, 2015 at 4:37 PM, Yuriy Tymchuk <[hidden email]> wrote: > >>> But are there numbered version to refer to? > >>> > >>> Uko > >>> > >>>> On 05 Jun 2015, at 16:34, Peter Uhnák <[hidden email]> wrote: > >>>> > >>>> > >>>> > >>>> On Fri, Jun 5, 2015 at 3:29 PM, Yuriy Tymchuk <[hidden email]> wrote: > >>>> I’m interested in participating. Personally I’d like to talk more about design decisions behind roassal ecosystem, release strategy and so on. Usually when I work with Roassal I have this issue that things are breaking because of rapid changes, or because of the differences between different parts of roassal. Maybe someone is also concerned about this, so we can discuss and maybe improve something… > >>>> > >>>> Yes I am also interested in this, right now I am actually using quite old version (month+) because I didn't have time to keep up. :) (Arguably 90% of my problems were from infamous composite shapes. :)) > >>>> > >>>> Peter > >>>> > >>>> Uko > >>>> > >>>>> On 04 Jun 2015, at 19:55, Alexandre Bergel <[hidden email]> wrote: > >>>>> > >>>>> Dear Colleagues and Friends, > >>>>> > >>>>> We are happy to announce we will organize a CampSmalltalk about the Roassal visualization engine, on _Sunday 12 July_. > >>>>> > >>>>> As far as we have seen, the interests are multiple. Here is a list of topics we will happy to work on: > >>>>> - Port of Roassal on VisualWorks > >>>>> - Using Roassal on Gemstone > >>>>> - HTML/JavaScript export > >>>>> - Improving Grapher, our charting library > >>>>> > >>>>> If you wish to participate, get in touch with us. Since we will probably have a sponsoring of the event, it would be nice to know how many will attend to ease the logistic and the pizza ordering :-) > >>>>> > >>>>> Cheers, > >>>>> Alexandre > >>>>> -- > >>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > >>>>> Alexandre Bergel http://www.bergel.eu > >>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > >>>>> > >>>>> > >>>>> > >>>>> > >>>> > >>>> > >>>> > >>> > >>> > >> > >> > > > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
|
|
In reply to this post by stepharo
Yes, but the problem is that stabilizing an API that does not work is not productive.
In any case, July will be decisive for Roassal as I intent to push the book. Alexandre > On Jun 15, 2015, at 4:00 AM, stepharo <[hidden email]> wrote: > > Hi Peter > > Definitively. Having stable API is key for us and for everybody. > For us (synectique), we stop to change versions around 6 months ago. > This is sad that we have to shield us from Roassal but this is what we are doing. > We cannot fight to get clients and change all the time our code. > As you see, I'm the only one to say it because usman already reported this problem one year > ago and we discussed with alex but we faced the same problem and now he stopped even to report > problems. > So we will rediscuss in july when alex is visiting us and else we will stay with an old version. > The problem is that the community around roassal will not benefit from this but > we cannot do much. > > Stef > >> Since I've already run into second thing in agile visualization book that is outdated (RTArrow, which was some time ago renamed to RTArrowedLine (https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/Roassal/0104-Roassal.html section 2.2) it made me wonder how many things like these are there (considering in neither case I was looking for errors). >> >> So, maybe this could be also addressed at the camp if there will be time? >> >> Writing is hard and reviewing own work is exercise in futility (I see things that I want to see, not what is there). Some of it (like the examples) could be even executed to verify their validity. >> >> And lastly what I saw in another thread (by stef) - graceful deprecation, and stabilization of API. >> >> Peter >> >> On Tue, Jun 9, 2015 at 9:57 PM, Yuriy Tymchuk <[hidden email]> wrote: >> >> > On 08 Jun 2015, at 18:22, Alexandre Bergel <[hidden email]> wrote: >> > >> >> Well at least for me it is certainly not clear what release policy is Roassal following; i.e. if I see a minor version change what to expect, if any BC breaks were introduced, etc. Of course this is extra effort for the person doing it, so it should be taken with care. But there are certainly things to be discussed about this. >> > >> > Hi Peter, >> > >> > Indeed, we have not been good at producing a descent version numbering schema. >> > My position was always this one: the last version should always fit your need. However, some product favored stability when Roassal is used in a commercial setting. >> > We will be more careful when updating the configuration with a proper version number. >> >> Versioning is in fact a complex thing. That’s why I suggest to have a brainstorming session during the camp. >> >> Uko >> >> > >> > Cheers, >> > Alexandre >> > >> > >> >> >> >> On Fri, Jun 5, 2015 at 7:31 PM, Yuriy Tymchuk <[hidden email]> wrote: >> >> Oh, then it’s my bad. Last time I’ve checked it seemed that it wasn’t updated for a long time. Maybe I was wrong. >> >> >> >> Uko >> >> >> >> >> >> >> >>> On 05 Jun 2015, at 18:08, Peter Uhnák <[hidden email]> wrote: >> >>> >> >>> There sure are, look at ConfigurationOfRoassal2>>version*: >> >>> >> >>> and in my baseline I have something like >> >>> >> >>> ~~~~~~~~~~~ >> >>> spec >> >>> project: 'Roassal2' with: [ >> >>> spec >> >>> className: #ConfigurationOfRoassal2; >> >>> versionString: '1.52'; >> >>> repository: 'http://smalltalkhub.com/mc/ObjectProfile/Roassal2/main/' ]; >> >>> ~~~~~~~~~~~ >> >>> >> >>> Peter >> >>> >> >>> On Fri, Jun 5, 2015 at 4:37 PM, Yuriy Tymchuk <[hidden email]> wrote: >> >>> But are there numbered version to refer to? >> >>> >> >>> Uko >> >>> >> >>>> On 05 Jun 2015, at 16:34, Peter Uhnák <[hidden email]> wrote: >> >>>> >> >>>> >> >>>> >> >>>> On Fri, Jun 5, 2015 at 3:29 PM, Yuriy Tymchuk <[hidden email]> wrote: >> >>>> I’m interested in participating. Personally I’d like to talk more about design decisions behind roassal ecosystem, release strategy and so on. Usually when I work with Roassal I have this issue that things are breaking because of rapid changes, or because of the differences between different parts of roassal. Maybe someone is also concerned about this, so we can discuss and maybe improve something… >> >>>> >> >>>> Yes I am also interested in this, right now I am actually using quite old version (month+) because I didn't have time to keep up. :) (Arguably 90% of my problems were from infamous composite shapes. :)) >> >>>> >> >>>> Peter >> >>>> >> >>>> Uko >> >>>> >> >>>>> On 04 Jun 2015, at 19:55, Alexandre Bergel <[hidden email]> wrote: >> >>>>> >> >>>>> Dear Colleagues and Friends, >> >>>>> >> >>>>> We are happy to announce we will organize a CampSmalltalk about the Roassal visualization engine, on _Sunday 12 July_. >> >>>>> >> >>>>> As far as we have seen, the interests are multiple. Here is a list of topics we will happy to work on: >> >>>>> - Port of Roassal on VisualWorks >> >>>>> - Using Roassal on Gemstone >> >>>>> - HTML/JavaScript export >> >>>>> - Improving Grapher, our charting library >> >>>>> >> >>>>> If you wish to participate, get in touch with us. Since we will probably have a sponsoring of the event, it would be nice to know how many will attend to ease the logistic and the pizza ordering :-) >> >>>>> >> >>>>> Cheers, >> >>>>> Alexandre >> >>>>> -- >> >>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> >>>>> Alexandre Bergel http://www.bergel.eu >> >>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>> >> >>>> >> >>>> >> >>> >> >>> >> >> >> >> >> > >> > -- >> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> > Alexandre Bergel http://www.bergel.eu >> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> > >> > >> > >> > >> >> >> > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
|
|
Alex
what are your criteria for knowing if this is stable? Because Roassal 2 got completely different from roassal 1. So people used mondrian, then roassal (the changes was important and good there). then we got roassal 2 which did not follow the same API and worse is changing. So from a user perspective rewriting is boring. So how do you assess that doing x that way is better expressed? How can we help stabilizing the API? Do not get me wrong I really want Roassal getting massively successful but it will not without: - data importers - stable API - a slice of statistics Stef Le 16/6/15 23:53, Alexandre Bergel a écrit : > Yes, but the problem is that stabilizing an API that does not work is not productive. > In any case, July will be decisive for Roassal as I intent to push the book. > > Alexandre > > >> On Jun 15, 2015, at 4:00 AM, stepharo <[hidden email]> wrote: >> >> Hi Peter >> >> Definitively. Having stable API is key for us and for everybody. >> For us (synectique), we stop to change versions around 6 months ago. >> This is sad that we have to shield us from Roassal but this is what we are doing. >> We cannot fight to get clients and change all the time our code. >> As you see, I'm the only one to say it because usman already reported this problem one year >> ago and we discussed with alex but we faced the same problem and now he stopped even to report >> problems. >> So we will rediscuss in july when alex is visiting us and else we will stay with an old version. >> The problem is that the community around roassal will not benefit from this but >> we cannot do much. >> >> Stef >> >>> Since I've already run into second thing in agile visualization book that is outdated (RTArrow, which was some time ago renamed to RTArrowedLine (https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/Roassal/0104-Roassal.html section 2.2) it made me wonder how many things like these are there (considering in neither case I was looking for errors). >>> >>> So, maybe this could be also addressed at the camp if there will be time? >>> >>> Writing is hard and reviewing own work is exercise in futility (I see things that I want to see, not what is there). Some of it (like the examples) could be even executed to verify their validity. >>> >>> And lastly what I saw in another thread (by stef) - graceful deprecation, and stabilization of API. >>> >>> Peter >>> >>> On Tue, Jun 9, 2015 at 9:57 PM, Yuriy Tymchuk <[hidden email]> wrote: >>> >>>> On 08 Jun 2015, at 18:22, Alexandre Bergel <[hidden email]> wrote: >>>> >>>>> Well at least for me it is certainly not clear what release policy is Roassal following; i.e. if I see a minor version change what to expect, if any BC breaks were introduced, etc. Of course this is extra effort for the person doing it, so it should be taken with care. But there are certainly things to be discussed about this. >>>> Hi Peter, >>>> >>>> Indeed, we have not been good at producing a descent version numbering schema. >>>> My position was always this one: the last version should always fit your need. However, some product favored stability when Roassal is used in a commercial setting. >>>> We will be more careful when updating the configuration with a proper version number. >>> Versioning is in fact a complex thing. That’s why I suggest to have a brainstorming session during the camp. >>> >>> Uko >>> >>>> Cheers, >>>> Alexandre >>>> >>>> >>>>> On Fri, Jun 5, 2015 at 7:31 PM, Yuriy Tymchuk <[hidden email]> wrote: >>>>> Oh, then it’s my bad. Last time I’ve checked it seemed that it wasn’t updated for a long time. Maybe I was wrong. >>>>> >>>>> Uko >>>>> >>>>> >>>>> >>>>>> On 05 Jun 2015, at 18:08, Peter Uhnák <[hidden email]> wrote: >>>>>> >>>>>> There sure are, look at ConfigurationOfRoassal2>>version*: >>>>>> >>>>>> and in my baseline I have something like >>>>>> >>>>>> ~~~~~~~~~~~ >>>>>> spec >>>>>> project: 'Roassal2' with: [ >>>>>> spec >>>>>> className: #ConfigurationOfRoassal2; >>>>>> versionString: '1.52'; >>>>>> repository: 'http://smalltalkhub.com/mc/ObjectProfile/Roassal2/main/' ]; >>>>>> ~~~~~~~~~~~ >>>>>> >>>>>> Peter >>>>>> >>>>>> On Fri, Jun 5, 2015 at 4:37 PM, Yuriy Tymchuk <[hidden email]> wrote: >>>>>> But are there numbered version to refer to? >>>>>> >>>>>> Uko >>>>>> >>>>>>> On 05 Jun 2015, at 16:34, Peter Uhnák <[hidden email]> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Fri, Jun 5, 2015 at 3:29 PM, Yuriy Tymchuk <[hidden email]> wrote: >>>>>>> I’m interested in participating. Personally I’d like to talk more about design decisions behind roassal ecosystem, release strategy and so on. Usually when I work with Roassal I have this issue that things are breaking because of rapid changes, or because of the differences between different parts of roassal. Maybe someone is also concerned about this, so we can discuss and maybe improve something… >>>>>>> >>>>>>> Yes I am also interested in this, right now I am actually using quite old version (month+) because I didn't have time to keep up. :) (Arguably 90% of my problems were from infamous composite shapes. :)) >>>>>>> >>>>>>> Peter >>>>>>> >>>>>>> Uko >>>>>>> >>>>>>>> On 04 Jun 2015, at 19:55, Alexandre Bergel <[hidden email]> wrote: >>>>>>>> >>>>>>>> Dear Colleagues and Friends, >>>>>>>> >>>>>>>> We are happy to announce we will organize a CampSmalltalk about the Roassal visualization engine, on _Sunday 12 July_. >>>>>>>> >>>>>>>> As far as we have seen, the interests are multiple. Here is a list of topics we will happy to work on: >>>>>>>> - Port of Roassal on VisualWorks >>>>>>>> - Using Roassal on Gemstone >>>>>>>> - HTML/JavaScript export >>>>>>>> - Improving Grapher, our charting library >>>>>>>> >>>>>>>> If you wish to participate, get in touch with us. Since we will probably have a sponsoring of the event, it would be nice to know how many will attend to ease the logistic and the pizza ordering :-) >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Alexandre >>>>>>>> -- >>>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>>>> Alexandre Bergel http://www.bergel.eu >>>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>> >>> >>> |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |