Brainstorming on the roadmap for first Pharo Consortium Engineer :)
Locked
123
123
Brainstorming on the roadmap for first Pharo Consortium Engineer :)
 
|
Hi guys
we have a roadmap for Esteban and we would like to share it with you. We have extra items that we would like to see fixed and we are welcoming your feedback/suggestions. Note this is typically the way we want to work with the consortium in the future: Build an initial roadmap and refine it based on the input of the community. - A website for the consortium registration (esteban is expert on that). - This is important for INRIA and for the visibility of the consortium. We should get new members :) - Integration with SmalltalkHub - Working on fixing bugs! - Debugger fixes - Continuous bug fixing. - Improving release process: faster, more people involved, simpler. - Working on metacello repositories for each distributions (everything is there but missing last bits) - Metacello tools - Automatic release validations - Automatic validation of fixes Now the free items with probably igor involvement - Multiwindowing support - Fully working multithreaded FFI with ***Documentation*** - Filesystem fix and integration - Integration of OPAL - RPackage integration Igor related - Ephemerons - Object format - VM branding - Use of new canvas - Event cleaning So we are waiting for your suggestions. Stef |
Re: Brainstorming on the roadmap for first Pharo Consortium Engineer :)
|
|
What about adding to this todo list:
-Fixing/finishing the Objective-C bridge :-) During ESUG 2010 Esteban told me that there was a pb with the Mac VM that causes the crash. I believe this wasn't fixed and this is the biggest issue with the MARS project. Noury On 31 oct. 2011, at 11:54, Stéphane Ducasse wrote: > Hi guys > > we have a roadmap for Esteban and we would like to share it with you. We have extra items that we would like to see fixed and we are welcoming your > feedback/suggestions. Note this is typically the way we want to work with the consortium in the future: > Build an initial roadmap and refine it based on the input of the community. > > - A website for the consortium registration (esteban is expert on that). > - This is important for INRIA and for the visibility of the consortium. We should get new members :) > - Integration with SmalltalkHub > > - Working on fixing bugs! > - Debugger fixes > - Continuous bug fixing. > > - Improving release process: faster, more people involved, simpler. > - Working on metacello repositories for each distributions (everything is there but missing last bits) > - Metacello tools > - Automatic release validations > - Automatic validation of fixes > > Now the free items with probably igor involvement > - Multiwindowing support > - Fully working multithreaded FFI with ***Documentation*** > - Filesystem fix and integration > - Integration of OPAL > - RPackage integration > > Igor related > - Ephemerons > - Object format > - VM branding > - Use of new canvas > - Event cleaning > > So we are waiting for your suggestions. > > > Stef > > > > Noury -- http://twitter.com/#!/NouryBouraqadi |
Re: Brainstorming on the roadmap for first Pharo Consortium Engineer :)
|
|
The object-c bridge is probably a big deal to the Mac users among us, right? My understand is that there are quite a few of you?? I've thought about it myself, but that's another story.
For external interfacing, I would very much like to see callbacks widely supported; I'm thinking of solvers/minimizers etc., where one needs to tell the library how to evaluate a function. FFI has been pretty good to me, and Andreas described something that might be turned into a reusable callback mechanism for it. Alien and NativeBoost are also options. It would be nice if we had one external interface system that does it all. ________________________________________ From: [hidden email] [[hidden email]] on behalf of Noury Bouraqadi [[hidden email]] Sent: Monday, October 31, 2011 11:17 AM To: [hidden email] Cc: A friendly place where any question about pharo is welcome Subject: Re: [Pharo-project] Brainstorming on the roadmap for first Pharo Consortium Engineer :) What about adding to this todo list: -Fixing/finishing the Objective-C bridge :-) During ESUG 2010 Esteban told me that there was a pb with the Mac VM that causes the crash. I believe this wasn't fixed and this is the biggest issue with the MARS project. Noury On 31 oct. 2011, at 11:54, Stéphane Ducasse wrote: > Hi guys > > we have a roadmap for Esteban and we would like to share it with you. We have extra items that we would like to see fixed and we are welcoming your > feedback/suggestions. Note this is typically the way we want to work with the consortium in the future: > Build an initial roadmap and refine it based on the input of the community. > > - A website for the consortium registration (esteban is expert on that). > - This is important for INRIA and for the visibility of the consortium. We should get new members :) > - Integration with SmalltalkHub > > - Working on fixing bugs! > - Debugger fixes > - Continuous bug fixing. > > - Improving release process: faster, more people involved, simpler. > - Working on metacello repositories for each distributions (everything is there but missing last bits) > - Metacello tools > - Automatic release validations > - Automatic validation of fixes > > Now the free items with probably igor involvement > - Multiwindowing support > - Fully working multithreaded FFI with ***Documentation*** > - Filesystem fix and integration > - Integration of OPAL > - RPackage integration > > Igor related > - Ephemerons > - Object format > - VM branding > - Use of new canvas > - Event cleaning > > So we are waiting for your suggestions. > > > Stef > > > > Noury -- http://twitter.com/#!/NouryBouraqadi |
Re: Brainstorming on the roadmap for first Pharo Consortium Engineer :)
|
Administrator
|
Yes! Thank you for the reminder, I'd temporarily given up and forgotten about this. A stable, well-documented ObjC bridge would be huge. My inability to effectively use it was one of the key drivers in my delving into debugging the VM. Like FFI, I think documentation will be extremely important here. Sean
Cheers,
Sean |
Re: Brainstorming on the roadmap for first Pharo Consortium Engineer :)
|
|
I can't take credit for thinking of the bridge, I was simply acknowledging it and the breadth of its audience as part of my shameless attempt to direct effort toward another feature that would get a lot of use :)
Bill ________________________________________ From: [hidden email] [[hidden email]] on behalf of Sean P. DeNigris [[hidden email]] Sent: Monday, October 31, 2011 3:22 PM To: [hidden email] Subject: Re: [Pharo-project] Brainstorming on the roadmap for first Pharo Consortium Engineer :) Schwab,Wilhelm K wrote: > > The object-c bridge is probably a big deal to the Mac users among us, > right? Yes! Thank you for the reminder, I'd temporarily given up and forgotten about this. A stable, well-documented ObjC bridge would be /huge/. My inability to effectively use it was one of the key drivers in my delving into debugging the VM. Like FFI, I think documentation will be extremely important here. Sean -- View this message in context: http://forum.world.st/Brainstorming-on-the-roadmap-for-first-Pharo-Consortium-Engineer-tp3955399p3959945.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. |
Re: Brainstorming on the roadmap for first Pharo Consortium Engineer :)
|
|
- Once again... I would LOVE to have a really working-out-of-the-box multithreaded FFI with callbacks.
This is a MUST if Pharo wants to be business friendly. - Unify the VMs. Have only ONE place where a single pharo user can go and pickup a VM. Have ANOTHER place for those bleeding edge or experiment VMs. This means merging gforge, jenkins, pharo website, pharo one click, etc. In addition, we need a way to IDENTIFY a VM. So that when someone reports a bug, we can exactly know which VM to reproduce it. - Integrate Nautilus with RB. Nobody (ok, most of us) cannot work without RB integration. Ok, integrations could live without that, but they INTEGRATE. If you are DEVELOPING you cannot develop without RB. If nobody will make OB to work in 1.4, then someone needs to integrate Nautilus with RB, otherwise people will stick with 1.3 and never change. - Make development really tools work in Pharo 1.4: OCompletion, Shout - Continue pushing Coral, Zinc, Ocean, DBXTalk, Fuel, Nautilus, etc. - Maintain issue tracker: let's give Marcus a rest. This means tagging issues, close them, validate, etc etc etc. Cheers On Mon, Oct 31, 2011 at 8:25 PM, Schwab,Wilhelm K <[hidden email]> wrote: I can't take credit for thinking of the bridge, I was simply acknowledging it and the breadth of its audience as part of my shameless attempt to direct effort toward another feature that would get a lot of use :) -- Mariano http://marianopeck.wordpress.com |
Re: Brainstorming on the roadmap for first Pharo Consortium Engineer :)
|
|
In reply to this post by Schwab,Wilhelm K
When igor release athens, we will really ask him to get a 100% fully working FFI will be the most important task
Stef On Oct 31, 2011, at 8:04 PM, Schwab,Wilhelm K wrote: > The object-c bridge is probably a big deal to the Mac users among us, right? My understand is that there are quite a few of you?? I've thought about it myself, but that's another story. > > For external interfacing, I would very much like to see callbacks widely supported; I'm thinking of solvers/minimizers etc., where one needs to tell the library how to evaluate a function. FFI has been pretty good to me, and Andreas described something that might be turned into a reusable callback mechanism for it. Alien and NativeBoost are also options. It would be nice if we had one external interface system that does it all. > > > > ________________________________________ > From: [hidden email] [[hidden email]] on behalf of Noury Bouraqadi [[hidden email]] > Sent: Monday, October 31, 2011 11:17 AM > To: [hidden email] > Cc: A friendly place where any question about pharo is welcome > Subject: Re: [Pharo-project] Brainstorming on the roadmap for first Pharo Consortium Engineer :) > > What about adding to this todo list: > > -Fixing/finishing the Objective-C bridge :-) > During ESUG 2010 Esteban told me that there was a pb with the Mac VM that causes the crash. > I believe this wasn't fixed and this is the biggest issue with the MARS project. > > Noury > On 31 oct. 2011, at 11:54, Stéphane Ducasse wrote: > >> Hi guys >> >> we have a roadmap for Esteban and we would like to share it with you. We have extra items that we would like to see fixed and we are welcoming your >> feedback/suggestions. Note this is typically the way we want to work with the consortium in the future: >> Build an initial roadmap and refine it based on the input of the community. >> >> - A website for the consortium registration (esteban is expert on that). >> - This is important for INRIA and for the visibility of the consortium. We should get new members :) >> - Integration with SmalltalkHub >> >> - Working on fixing bugs! >> - Debugger fixes >> - Continuous bug fixing. >> >> - Improving release process: faster, more people involved, simpler. >> - Working on metacello repositories for each distributions (everything is there but missing last bits) >> - Metacello tools >> - Automatic release validations >> - Automatic validation of fixes >> >> Now the free items with probably igor involvement >> - Multiwindowing support >> - Fully working multithreaded FFI with ***Documentation*** >> - Filesystem fix and integration >> - Integration of OPAL >> - RPackage integration >> >> Igor related >> - Ephemerons >> - Object format >> - VM branding >> - Use of new canvas >> - Event cleaning >> >> So we are waiting for your suggestions. >> >> >> Stef >> >> >> >> > > Noury > -- > http://twitter.com/#!/NouryBouraqadi > > > > > > > |
|
|
Hi,
ObjectiveCBridge2 (John's one) should be working with latest builds... at least I *think* it should be (the older bug was fixed... so if it does not works now is probably because other reasons. I didn't check it since last six months, so I don't know. Reason why I didn't check it? well... two reasons: nobody ask for, so I assumed I was the only user (sorry if that's not true), and also, in my work of mars/deimos I found several performace issues (most people will not have it, but mars/deimos is very callback dependent) and objective-c callback architecture was not enough, so I started to create (well... to finish, because machinery was already there) a new objective-c bridge, based on Alien... it was working (and the response times were incredible fast), but then came the new FFI (not threaded) and I started migrating the alien objective-c bridge to the new plugin... and well... that's not finished because time is never enough :) I think in the long way the new plugin is the way to go, but for now we have the bridge and it should work :) So, as a summary: ObjectiveCBridge2 *should* be working, if anyone want to take a look, I will be happy to help if there are any problems. Cheers, Esteban El 31/10/2011, a las 5:58p.m., Stéphane Ducasse escribió: > When igor release athens, we will really ask him to get a 100% fully working FFI will be the most important task > > Stef > > On Oct 31, 2011, at 8:04 PM, Schwab,Wilhelm K wrote: > >> The object-c bridge is probably a big deal to the Mac users among us, right? My understand is that there are quite a few of you?? I've thought about it myself, but that's another story. >> >> For external interfacing, I would very much like to see callbacks widely supported; I'm thinking of solvers/minimizers etc., where one needs to tell the library how to evaluate a function. FFI has been pretty good to me, and Andreas described something that might be turned into a reusable callback mechanism for it. Alien and NativeBoost are also options. It would be nice if we had one external interface system that does it all. >> >> >> >> ________________________________________ >> From: [hidden email] [[hidden email]] on behalf of Noury Bouraqadi [[hidden email]] >> Sent: Monday, October 31, 2011 11:17 AM >> To: [hidden email] >> Cc: A friendly place where any question about pharo is welcome >> Subject: Re: [Pharo-project] Brainstorming on the roadmap for first Pharo Consortium Engineer :) >> >> What about adding to this todo list: >> >> -Fixing/finishing the Objective-C bridge :-) >> During ESUG 2010 Esteban told me that there was a pb with the Mac VM that causes the crash. >> I believe this wasn't fixed and this is the biggest issue with the MARS project. >> >> Noury >> On 31 oct. 2011, at 11:54, Stéphane Ducasse wrote: >> >>> Hi guys >>> >>> we have a roadmap for Esteban and we would like to share it with you. We have extra items that we would like to see fixed and we are welcoming your >>> feedback/suggestions. Note this is typically the way we want to work with the consortium in the future: >>> Build an initial roadmap and refine it based on the input of the community. >>> >>> - A website for the consortium registration (esteban is expert on that). >>> - This is important for INRIA and for the visibility of the consortium. We should get new members :) >>> - Integration with SmalltalkHub >>> >>> - Working on fixing bugs! >>> - Debugger fixes >>> - Continuous bug fixing. >>> >>> - Improving release process: faster, more people involved, simpler. >>> - Working on metacello repositories for each distributions (everything is there but missing last bits) >>> - Metacello tools >>> - Automatic release validations >>> - Automatic validation of fixes >>> >>> Now the free items with probably igor involvement >>> - Multiwindowing support >>> - Fully working multithreaded FFI with ***Documentation*** >>> - Filesystem fix and integration >>> - Integration of OPAL >>> - RPackage integration >>> >>> Igor related >>> - Ephemerons >>> - Object format >>> - VM branding >>> - Use of new canvas >>> - Event cleaning >>> >>> So we are waiting for your suggestions. >>> >>> >>> Stef >>> >>> >>> >>> >> >> Noury >> -- >> http://twitter.com/#!/NouryBouraqadi >> >> >> >> >> >> >> > > |
Re: Brainstorming on the roadmap for first Pharo Consortium Engineer :)
|
|
esteban
would mars be the perfect case to validate the FFI we all need? Stef On Oct 31, 2011, at 10:33 PM, Esteban Lorenzano wrote: > Hi, > > ObjectiveCBridge2 (John's one) should be working with latest builds... at least I *think* it should be (the older bug was fixed... so if it does not works now is probably because other reasons. I didn't check it since last six months, so I don't know. Reason why I didn't check it? well... two reasons: nobody ask for, so I assumed I was the only user (sorry if that's not true), and also, in my work of mars/deimos I found several performace issues (most people will not have it, but mars/deimos is very callback dependent) and objective-c callback architecture was not enough, so I started to create (well... to finish, because machinery was already there) a new objective-c bridge, based on Alien... it was working (and the response times were incredible fast), but then came the new FFI (not threaded) and I started migrating the alien objective-c bridge to the new plugin... and well... that's not finished because time is never enough :) > I think in the long way the new plugin is the way to go, but for now we have the bridge and it should work :) > > So, as a summary: ObjectiveCBridge2 *should* be working, if anyone want to take a look, I will be happy to help if there are any problems. > > Cheers, > Esteban > > El 31/10/2011, a las 5:58p.m., Stéphane Ducasse escribió: > >> When igor release athens, we will really ask him to get a 100% fully working FFI will be the most important task >> >> Stef >> >> On Oct 31, 2011, at 8:04 PM, Schwab,Wilhelm K wrote: >> >>> The object-c bridge is probably a big deal to the Mac users among us, right? My understand is that there are quite a few of you?? I've thought about it myself, but that's another story. >>> >>> For external interfacing, I would very much like to see callbacks widely supported; I'm thinking of solvers/minimizers etc., where one needs to tell the library how to evaluate a function. FFI has been pretty good to me, and Andreas described something that might be turned into a reusable callback mechanism for it. Alien and NativeBoost are also options. It would be nice if we had one external interface system that does it all. >>> >>> >>> >>> ________________________________________ >>> From: [hidden email] [[hidden email]] on behalf of Noury Bouraqadi [[hidden email]] >>> Sent: Monday, October 31, 2011 11:17 AM >>> To: [hidden email] >>> Cc: A friendly place where any question about pharo is welcome >>> Subject: Re: [Pharo-project] Brainstorming on the roadmap for first Pharo Consortium Engineer :) >>> >>> What about adding to this todo list: >>> >>> -Fixing/finishing the Objective-C bridge :-) >>> During ESUG 2010 Esteban told me that there was a pb with the Mac VM that causes the crash. >>> I believe this wasn't fixed and this is the biggest issue with the MARS project. >>> >>> Noury >>> On 31 oct. 2011, at 11:54, Stéphane Ducasse wrote: >>> >>>> Hi guys >>>> >>>> we have a roadmap for Esteban and we would like to share it with you. We have extra items that we would like to see fixed and we are welcoming your >>>> feedback/suggestions. Note this is typically the way we want to work with the consortium in the future: >>>> Build an initial roadmap and refine it based on the input of the community. >>>> >>>> - A website for the consortium registration (esteban is expert on that). >>>> - This is important for INRIA and for the visibility of the consortium. We should get new members :) >>>> - Integration with SmalltalkHub >>>> >>>> - Working on fixing bugs! >>>> - Debugger fixes >>>> - Continuous bug fixing. >>>> >>>> - Improving release process: faster, more people involved, simpler. >>>> - Working on metacello repositories for each distributions (everything is there but missing last bits) >>>> - Metacello tools >>>> - Automatic release validations >>>> - Automatic validation of fixes >>>> >>>> Now the free items with probably igor involvement >>>> - Multiwindowing support >>>> - Fully working multithreaded FFI with ***Documentation*** >>>> - Filesystem fix and integration >>>> - Integration of OPAL >>>> - RPackage integration >>>> >>>> Igor related >>>> - Ephemerons >>>> - Object format >>>> - VM branding >>>> - Use of new canvas >>>> - Event cleaning >>>> >>>> So we are waiting for your suggestions. >>>> >>>> >>>> Stef >>>> >>>> >>>> >>>> >>> >>> Noury >>> -- >>> http://twitter.com/#!/NouryBouraqadi >>> >>> >>> >>> >>> >>> >>> >> >> > > |
|
|
I think so, yes :)
El 31/10/2011, a las 6:40p.m., Stéphane Ducasse escribió: > esteban > > would mars be the perfect case to validate the FFI we all need? > > Stef > > On Oct 31, 2011, at 10:33 PM, Esteban Lorenzano wrote: > >> Hi, >> >> ObjectiveCBridge2 (John's one) should be working with latest builds... at least I *think* it should be (the older bug was fixed... so if it does not works now is probably because other reasons. I didn't check it since last six months, so I don't know. Reason why I didn't check it? well... two reasons: nobody ask for, so I assumed I was the only user (sorry if that's not true), and also, in my work of mars/deimos I found several performace issues (most people will not have it, but mars/deimos is very callback dependent) and objective-c callback architecture was not enough, so I started to create (well... to finish, because machinery was already there) a new objective-c bridge, based on Alien... it was working (and the response times were incredible fast), but then came the new FFI (not threaded) and I started migrating the alien objective-c bridge to the new plugin... and well... that's not finished because time is never enough :) >> I think in the long way the new plugin is the way to go, but for now we have the bridge and it should work :) >> >> So, as a summary: ObjectiveCBridge2 *should* be working, if anyone want to take a look, I will be happy to help if there are any problems. >> >> Cheers, >> Esteban >> >> El 31/10/2011, a las 5:58p.m., Stéphane Ducasse escribió: >> >>> When igor release athens, we will really ask him to get a 100% fully working FFI will be the most important task >>> >>> Stef >>> >>> On Oct 31, 2011, at 8:04 PM, Schwab,Wilhelm K wrote: >>> >>>> The object-c bridge is probably a big deal to the Mac users among us, right? My understand is that there are quite a few of you?? I've thought about it myself, but that's another story. >>>> >>>> For external interfacing, I would very much like to see callbacks widely supported; I'm thinking of solvers/minimizers etc., where one needs to tell the library how to evaluate a function. FFI has been pretty good to me, and Andreas described something that might be turned into a reusable callback mechanism for it. Alien and NativeBoost are also options. It would be nice if we had one external interface system that does it all. >>>> >>>> >>>> >>>> ________________________________________ >>>> From: [hidden email] [[hidden email]] on behalf of Noury Bouraqadi [[hidden email]] >>>> Sent: Monday, October 31, 2011 11:17 AM >>>> To: [hidden email] >>>> Cc: A friendly place where any question about pharo is welcome >>>> Subject: Re: [Pharo-project] Brainstorming on the roadmap for first Pharo Consortium Engineer :) >>>> >>>> What about adding to this todo list: >>>> >>>> -Fixing/finishing the Objective-C bridge :-) >>>> During ESUG 2010 Esteban told me that there was a pb with the Mac VM that causes the crash. >>>> I believe this wasn't fixed and this is the biggest issue with the MARS project. >>>> >>>> Noury >>>> On 31 oct. 2011, at 11:54, Stéphane Ducasse wrote: >>>> >>>>> Hi guys >>>>> >>>>> we have a roadmap for Esteban and we would like to share it with you. We have extra items that we would like to see fixed and we are welcoming your >>>>> feedback/suggestions. Note this is typically the way we want to work with the consortium in the future: >>>>> Build an initial roadmap and refine it based on the input of the community. >>>>> >>>>> - A website for the consortium registration (esteban is expert on that). >>>>> - This is important for INRIA and for the visibility of the consortium. We should get new members :) >>>>> - Integration with SmalltalkHub >>>>> >>>>> - Working on fixing bugs! >>>>> - Debugger fixes >>>>> - Continuous bug fixing. >>>>> >>>>> - Improving release process: faster, more people involved, simpler. >>>>> - Working on metacello repositories for each distributions (everything is there but missing last bits) >>>>> - Metacello tools >>>>> - Automatic release validations >>>>> - Automatic validation of fixes >>>>> >>>>> Now the free items with probably igor involvement >>>>> - Multiwindowing support >>>>> - Fully working multithreaded FFI with ***Documentation*** >>>>> - Filesystem fix and integration >>>>> - Integration of OPAL >>>>> - RPackage integration >>>>> >>>>> Igor related >>>>> - Ephemerons >>>>> - Object format >>>>> - VM branding >>>>> - Use of new canvas >>>>> - Event cleaning >>>>> >>>>> So we are waiting for your suggestions. >>>>> >>>>> >>>>> Stef >>>>> >>>>> >>>>> >>>>> >>>> >>>> Noury >>>> -- >>>> http://twitter.com/#!/NouryBouraqadi >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >> >> > > |
Re: Brainstorming on the roadmap for first Pharo Consortium Engineer :)
|
|
In reply to this post by Stéphane Ducasse
On Mon, Oct 31, 2011 at 10:40 PM, Stéphane Ducasse <[hidden email]> wrote: esteban DBXTalk is a perfect candidate for the multithreaded part (not the callback since we do not use callbacks) Stef -- Mariano http://marianopeck.wordpress.com |
Re: Brainstorming on the roadmap for first Pharo Consortium Engineer :)
|
|
In reply to this post by Stéphane Ducasse
Excellent news!
________________________________________ From: [hidden email] [[hidden email]] on behalf of Stéphane Ducasse [[hidden email]] Sent: Monday, October 31, 2011 4:58 PM To: [hidden email] Subject: Re: [Pharo-project] Brainstorming on the roadmap for first Pharo Consortium Engineer :) When igor release athens, we will really ask him to get a 100% fully working FFI will be the most important task Stef On Oct 31, 2011, at 8:04 PM, Schwab,Wilhelm K wrote: > The object-c bridge is probably a big deal to the Mac users among us, right? My understand is that there are quite a few of you?? I've thought about it myself, but that's another story. > > For external interfacing, I would very much like to see callbacks widely supported; I'm thinking of solvers/minimizers etc., where one needs to tell the library how to evaluate a function. FFI has been pretty good to me, and Andreas described something that might be turned into a reusable callback mechanism for it. Alien and NativeBoost are also options. It would be nice if we had one external interface system that does it all. > > > > ________________________________________ > From: [hidden email] [[hidden email]] on behalf of Noury Bouraqadi [[hidden email]] > Sent: Monday, October 31, 2011 11:17 AM > To: [hidden email] > Cc: A friendly place where any question about pharo is welcome > Subject: Re: [Pharo-project] Brainstorming on the roadmap for first Pharo Consortium Engineer :) > > What about adding to this todo list: > > -Fixing/finishing the Objective-C bridge :-) > During ESUG 2010 Esteban told me that there was a pb with the Mac VM that causes the crash. > I believe this wasn't fixed and this is the biggest issue with the MARS project. > > Noury > On 31 oct. 2011, at 11:54, Stéphane Ducasse wrote: > >> Hi guys >> >> we have a roadmap for Esteban and we would like to share it with you. We have extra items that we would like to see fixed and we are welcoming your >> feedback/suggestions. Note this is typically the way we want to work with the consortium in the future: >> Build an initial roadmap and refine it based on the input of the community. >> >> - A website for the consortium registration (esteban is expert on that). >> - This is important for INRIA and for the visibility of the consortium. We should get new members :) >> - Integration with SmalltalkHub >> >> - Working on fixing bugs! >> - Debugger fixes >> - Continuous bug fixing. >> >> - Improving release process: faster, more people involved, simpler. >> - Working on metacello repositories for each distributions (everything is there but missing last bits) >> - Metacello tools >> - Automatic release validations >> - Automatic validation of fixes >> >> Now the free items with probably igor involvement >> - Multiwindowing support >> - Fully working multithreaded FFI with ***Documentation*** >> - Filesystem fix and integration >> - Integration of OPAL >> - RPackage integration >> >> Igor related >> - Ephemerons >> - Object format >> - VM branding >> - Use of new canvas >> - Event cleaning >> >> So we are waiting for your suggestions. >> >> >> Stef >> >> >> >> > > Noury > -- > http://twitter.com/#!/NouryBouraqadi > > > > > > > |
Re: Brainstorming on the roadmap for first Pharo Consortium Engineer :)
|
|
In reply to this post by Mariano Martinez Peck
On Oct 31, 2011, at 9:56 PM, Mariano Martinez Peck wrote: - Once again... I would LOVE to have a really working-out-of-the-box multithreaded FFI with callbacks. I am on it, but it's long, i have to understand fully how it works, and since I never really used it (I am still a newbie ^^) it's not so easy. Moreover I have to go through OB code which is still obscure to me. But it progresses step by step :) Ben - Make development really tools work in Pharo 1.4: OCompletion, Shout |
Re: Brainstorming on the roadmap for first Pharo Consortium Engineer :)
|
|
On Tue, Nov 1, 2011 at 4:25 AM, Benjamin <[hidden email]> wrote:
that's why I say "someone" and not Ben :)
Sure, and continue like that!
-- Mariano http://marianopeck.wordpress.com |
|
|
In reply to this post by Stéphane Ducasse
Stéphane Ducasse wrote:
> Hi guys > > we have a roadmap for Esteban and we would like to share it with you. We have extra items that we would like to see fixed and we are welcoming your > feedback/suggestions. Note this is typically the way we want to work with the consortium in the future: > Build an initial roadmap and refine it based on the input of the community. > > - A website for the consortium registration (esteban is expert on that). > - This is important for INRIA and for the visibility of the consortium. We should get new members :) > - Integration with SmalltalkHub > > - Working on fixing bugs! > - Debugger fixes > - Continuous bug fixing. > > - Improving release process: faster, more people involved, simpler. > - Working on metacello repositories for each distributions (everything is there but missing last bits) > - Metacello tools > - Automatic release validations > - Automatic validation of fixes > > Now the free items with probably igor involvement > - Multiwindowing support > - Fully working multithreaded FFI with ***Documentation*** > - Filesystem fix and integration > - Integration of OPAL > - RPackage integration > > Igor related > - Ephemerons > - Object format > - VM branding > - Use of new canvas > - Event cleaning > > So we are waiting for your suggestions. > > > Stef to work on the sexy stuff. One of the downsides of open-source is the chance that developers might focus on the fun 80% of their ideas before moving on to the next-big-thing(c). It is easy to develop something to be used by oneself. It is much harder to develop something to be used by others - particularly in providing a sense of how to use the system by way of well documented examples. There is a lot of drudge work to make a system successful and stable. Knowing there is a paid position that might deal with part of that work definitely increases confidence in the system. One new idea. I really like the way Wordpress manages their thousands of Plugins with the "Compatability" sidebox where you choose a Wordpress version and a Plugin version and it indicates how compatible they are based on user votes. However rather than (or as well as) user voting I think that TestRunner results from applications could be used - and also presented in a tabulated form rather than just pull-down choices showing a single sample point. A continuous integration and testing system would take combinatorial approach to testing registered Metacello configurations - which might take a lot of processing power and leads to... A second idea for a distributed continuous integration test system. I would personally be happy to contribute cpu cycles to running a Pharo test system on top of a virtual machine, which from a central server obtains a random set of Metacello configurations to install, runs tests and reports results to the central server. Apart from gaining the processing power to possibly test all permutations of configurations, it also provides a way for new community members to feel like they are contributing, which preceeds them getting more involved. As an example in line with my first comment, perhaps the initial proof of concept would be done as a research project, and then the paid professional would polish off the stability and usability of it. cheers, Ben |
|
|
I meant to link to this as an example of the Wordpress "Compatability"
rating system
[1] http://wordpress.org/extend/plugins/buddypress/ Ben Coman wrote: Stéphane Ducasse wrote: One new idea. I really like the way Wordpress manages their thousands of Plugins with the "Compatability" sidebox [1] where you choose a Wordpress version and a Plugin version and it indicates how compatible they are based on user votes. However rather than (or as well as) user voting I think that TestRunner results from applications could be used - and also presented in a tabulated form rather than just pull-down choices showing a single sample point. A continuous integration and testing system would take combinatorial approach to testing registered Metacello configurations - which might take a lot of processing power and leads to... |
Re: Brainstorming on the roadmap for first Pharo Consortium Engineer :)
|
|
In reply to this post by Ben Coman
Ben
what we want is the following - we have different distributions for pharo1.0, 1.2.14 and automatically we run tests and rules checking systematically - when a package has too many flagged items -> goes into the inbox of the distributions - Package should embed their false positive to SmallLint so that we can run them for real. - when people propose fixes we want the system to automatically load and test. This is what Ulysse the Monkey is already doing and this is great >> >> >> Stef > Just a very general view... that in paid positions, you don't always get to work on the sexy stuff. One of the downsides of open-source is the chance that developers might focus on the fun 80% of their ideas before moving on to the next-big-thing(c). It is easy to develop something to be used by oneself. It is much harder to develop something to be used by others - particularly in providing a sense of how to use the system by way of well documented examples. There is a lot of drudge work to make a system successful and stable. Knowing there is a paid position that might deal with part of that work definitely increases confidence in the system. > One new idea. I really like the way Wordpress manages their thousands of Plugins with the "Compatability" sidebox where you choose a Wordpress version and a Plugin version and it indicates how compatible they are based on user votes. However rather than (or as well as) user voting I think that TestRunner results from applications could be used - and also presented in a tabulated form rather than just pull-down choices showing a single sample point. A continuous integration and testing system would take combinatorial approach to testing registered Metacello configurations - which might take a lot of processing power and leads to... > > A second idea for a distributed continuous integration test system. I would personally be happy to contribute cpu cycles to running a Pharo test system on top of a virtual machine, which from a central server obtains a random set of Metacello configurations to install, runs tests and reports results to the central server. Apart from gaining the processing power to possibly test all permutations of configurations, it also provides a way for new community members to feel like they are contributing, which preceeds them getting more involved. As an example in line with my first comment, perhaps the initial proof of concept would be done as a research project, and then the paid professional would polish off the stability and usability of it. Yes this is a neat idea :) To contribute you can already load a fixe and tell us if the tests are ok. Or just if the fix is loading :). Stef > > cheers, Ben > |
FW: Brainstorming on the roadmap for first Pharo Consortium Engineer :)
|
|
In reply to this post by Ben Coman
[This appears to have bounced - trying again]
Ben, That's an interesting idea. I'm sad to say that we would need to think about security in the receipt of data. Just as we now have signed license agreements, we might need to have certificates and keys for publishing test results. Passwords might be sufficient and easier to manage. An existing server would likely end up with a Seaside app that allows mere mortals to request a signing or a password. After moderator approval (also part of the app), the tester would be given or emailed to retrieve the credentials needed to post test results. BTW, none of that makes it a bad idea or "too hard." I just fear that we would regret having a wide-open way to trash our test results data. Bill ________________________________________ From: [hidden email] [[hidden email]] on behalf of Ben Coman [[hidden email]] Sent: Tuesday, November 01, 2011 10:00 AM To: [hidden email] Subject: Re: [Pharo-project] Brainstorming on the roadmap for first Pharo Consortium Engineer :) A second idea for a distributed continuous integration test system. I would personally be happy to contribute cpu cycles to running a Pharo test system on top of a virtual machine, which from a central server obtains a random set of Metacello configurations to install, runs tests and reports results to the central server. Apart from gaining the processing power to possibly test all permutations of configurations, it also provides a way for new community members to feel like they are contributing, which preceeds them getting more involved. As an example in line with my first comment, perhaps the initial proof of concept would be done as a research project, and then the paid professional would polish off the stability and usability of it. cheers, Ben |
Re: [Pharo-users] Brainstorming on the roadmap for first Pharo Consortium Engineer :)
|
|
In reply to this post by Stéphane Ducasse
Am 31.10.2011 um 11:54 schrieb Stéphane Ducasse: Now the free items with probably igor involvement I like to add environments so we can have multiple versions in the same image and get rid of default global state. I think you have that already on your mind even with separate object memories. Norbert |
Re: [Pharo-users] Brainstorming on the roadmap for first Pharo Consortium Engineer :)
|
|
How about new source code management?
In terms of: - better abstraction of source code access in image - create a shared repository (database) , which can be used to browse the history of all source code of Pharo and its predecessor up to Squeak 1.0. We are discussed this idea couple times, and we already having some pieces of puzzle , like Ring. Also, there is already a project made by someone (forgot the name) , who already storing all source code in database and managing it there. -- Best regards, Igor Stasenko. |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |