[Pharo-project] 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
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
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: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Noury Bouraqadi [bouraqadi@gmail.com] Sent: Monday, October 31, 2011 11:17 AM To: Pharo-project@lists.gforge.inria.fr 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
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-Consortiu... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
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: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Sean P. DeNigris [sean@clipperadams.com] Sent: Monday, October 31, 2011 3:22 PM To: pharo-project@lists.gforge.inria.fr 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-Consortiu... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
- 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 <bschwab@anest.ufl.edu>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 :)
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [ pharo-project-bounces@lists.gforge.inria.fr] on behalf of Sean P. DeNigris [sean@clipperadams.com] Sent: Monday, October 31, 2011 3:22 PM To: pharo-project@lists.gforge.inria.fr 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-Consortiu... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
-- Mariano http://marianopeck.wordpress.com
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. 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.
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
- 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 <bschwab@anest.ufl.edu> 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 :)
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Sean P. DeNigris [sean@clipperadams.com] Sent: Monday, October 31, 2011 3:22 PM To: pharo-project@lists.gforge.inria.fr 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-Consortiu... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
-- Mariano http://marianopeck.wordpress.com
On Tue, Nov 1, 2011 at 4:25 AM, Benjamin < benjamin.vanryseghem.pharo@gmail.com> wrote:
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. 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.
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.
that's why I say "someone" and not Ben :)
But it progresses step by step :)
Sure, and continue like that!
Ben
- 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 <bschwab@anest.ufl.edu>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 :)
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [ pharo-project-bounces@lists.gforge.inria.fr] on behalf of Sean P. DeNigris [sean@clipperadams.com] Sent: Monday, October 31, 2011 3:22 PM To: pharo-project@lists.gforge.inria.fr 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-Consortiu... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
-- Mariano http://marianopeck.wordpress.com
-- Mariano http://marianopeck.wordpress.com
On Mon, Oct 31, 2011 at 1:56 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
- Once again... I would LOVE to have a really working-out-of-the-box multithreaded FFI with callbacks.
and for me to finish my part of this (the VM implementation and Alien support) I need review of my VM code. Since Cadence want this too I should be in a position to spend considerable time on it in a few weeks.
This is a MUST if Pharo wants to be business friendly.
I couldn't agree more. A platform must have an excellent FFI to be useful.
- 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 <bschwab@anest.ufl.edu>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 :)
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [ pharo-project-bounces@lists.gforge.inria.fr] on behalf of Sean P. DeNigris [sean@clipperadams.com] Sent: Monday, October 31, 2011 3:22 PM To: pharo-project@lists.gforge.inria.fr 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-Consortiu... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
-- Mariano http://marianopeck.wordpress.com
-- best, Eliot
2011/11/2 Eliot Miranda <eliot.miranda@gmail.com>
On Mon, Oct 31, 2011 at 1:56 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
- Once again... I would LOVE to have a really working-out-of-the-box multithreaded FFI with callbacks.
and for me to finish my part of this (the VM implementation and Alien support) I need review of my VM code. Since Cadence want this too I should be in a position to spend considerable time on it in a few weeks.
really great news! Luc
This is a MUST if Pharo wants to be business friendly.
I couldn't agree more. A platform must have an excellent FFI to be useful.
- 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 <bschwab@anest.ufl.edu>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 :)
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [ pharo-project-bounces@lists.gforge.inria.fr] on behalf of Sean P. DeNigris [sean@clipperadams.com] Sent: Monday, October 31, 2011 3:22 PM To: pharo-project@lists.gforge.inria.fr 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-Consortiu... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
-- Mariano http://marianopeck.wordpress.com
-- best, Eliot
excellent news
- Once again... I would LOVE to have a really working-out-of-the-box multithreaded FFI with callbacks.
and for me to finish my part of this (the VM implementation and Alien support) I need review of my VM code. Since Cadence want this too I should be in a position to spend considerable time on it in a few weeks.
This is a MUST if Pharo wants to be business friendly.
I couldn't agree more. A platform must have an excellent FFI to be useful.
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: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Noury Bouraqadi [bouraqadi@gmail.com] Sent: Monday, October 31, 2011 11:17 AM To: Pharo-project@lists.gforge.inria.fr 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: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Noury Bouraqadi [bouraqadi@gmail.com] Sent: Monday, October 31, 2011 11:17 AM To: Pharo-project@lists.gforge.inria.fr 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
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: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Noury Bouraqadi [bouraqadi@gmail.com] Sent: Monday, October 31, 2011 11:17 AM To: Pharo-project@lists.gforge.inria.fr 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: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Noury Bouraqadi [bouraqadi@gmail.com] Sent: Monday, October 31, 2011 11:17 AM To: Pharo-project@lists.gforge.inria.fr 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
On Mon, Oct 31, 2011 at 10:40 PM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote:
esteban
would mars be the perfect case to validate the FFI we all need?
DBXTalk is a perfect candidate for the multithreaded part (not the callback since we do not use callbacks)
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: pharo-project-bounces@lists.gforge.inria.fr [ pharo-project-bounces@lists.gforge.inria.fr] on behalf of Noury Bouraqadi [bouraqadi@gmail.com] Sent: Monday, October 31, 2011 11:17 AM To: Pharo-project@lists.gforge.inria.fr 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
-- Mariano http://marianopeck.wordpress.com
Excellent news! ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Stéphane Ducasse [stephane.ducasse@inria.fr] Sent: Monday, October 31, 2011 4:58 PM To: Pharo-project@lists.gforge.inria.fr 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: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Noury Bouraqadi [bouraqadi@gmail.com] Sent: Monday, October 31, 2011 11:17 AM To: Pharo-project@lists.gforge.inria.fr 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
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 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. cheers, Ben
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
Am 31.10.2011 um 11:54 schrieb Stéphane Ducasse:
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
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
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.
Static git repository of the source code of Squeak and Pharo until Squeak version 4 and Pharo 1: http://scg.unibe.ch/research/Pharogenesis https://github.com/pharogenesis The source code layout (tree of directories and files) could probably be better. But I guess one could use it as proof of concept. Max On 02.11.2011, at 15:27, Igor Stasenko wrote:
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.
On 2 November 2011 15:42, Max Leske <maxleske@gmail.com> wrote:
Static git repository of the source code of Squeak and Pharo until Squeak version 4 and Pharo 1: http://scg.unibe.ch/research/Pharogenesis https://github.com/pharogenesis
The source code layout (tree of directories and files) could probably be better. But I guess one could use it as proof of concept.
Ah, so you will be second one :) I meant another project in mind. There was a ?thesis? of some student to store all source code in sql database. instead of .changes and .source files integrated into an image.
Max
On 02.11.2011, at 15:27, Igor Stasenko wrote:
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.
-- Best regards, Igor Stasenko.
:D Interesting! On 02.11.2011, at 18:59, Igor Stasenko wrote:
On 2 November 2011 15:42, Max Leske <maxleske@gmail.com> wrote:
Static git repository of the source code of Squeak and Pharo until Squeak version 4 and Pharo 1: http://scg.unibe.ch/research/Pharogenesis https://github.com/pharogenesis
The source code layout (tree of directories and files) could probably be better. But I guess one could use it as proof of concept.
Ah, so you will be second one :) I meant another project in mind. There was a ?thesis? of some student to store all source code in sql database. instead of .changes and .source files integrated into an image.
Max
On 02.11.2011, at 15:27, Igor Stasenko wrote:
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.
-- Best regards, Igor Stasenko.
Yes but now I was more thinking about what is urgent to get done. Stef
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.
I always thought, the IMAGE *is* already an OO database!?? Guido Stepken Am 02.11.2011 um 15:27 schrieb Igor Stasenko <siguctua@gmail.com>:
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.
Am 03.11.2011 um 12:57 schrieb Guido Stepken:
I always thought, the IMAGE *is* already an OO database!??
Yes, it is an OO database with a restriction in the size of your volatile memory (unless you use GemStone or LOOM) Norbert
Guido Stepken
Am 02.11.2011 um 15:27 schrieb Igor Stasenko <siguctua@gmail.com>:
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.
Should be very easy to introduce reference pointers towards a number of additional images.... Am 03.11.2011 um 13:05 schrieb Norbert Hartl <norbert@hartl.name>:
Am 03.11.2011 um 12:57 schrieb Guido Stepken:
I always thought, the IMAGE *is* already an OO database!??
Yes, it is an OO database with a restriction in the size of your volatile memory (unless you use GemStone or LOOM)
Norbert
Guido Stepken
Am 02.11.2011 um 15:27 schrieb Igor Stasenko <siguctua@gmail.com>:
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.
Am 03.11.2011 um 13:13 schrieb Guido Stepken:
Should be very easy to introduce reference pointers towards a number of additional images....
Well, sure. Drop us a note when you have it ready. Norbert
Am 03.11.2011 um 13:05 schrieb Norbert Hartl <norbert@hartl.name>:
Am 03.11.2011 um 12:57 schrieb Guido Stepken:
I always thought, the IMAGE *is* already an OO database!??
Yes, it is an OO database with a restriction in the size of your volatile memory (unless you use GemStone or LOOM)
Norbert
Guido Stepken
Am 02.11.2011 um 15:27 schrieb Igor Stasenko <siguctua@gmail.com>:
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.
On 3 November 2011 12:57, Guido Stepken <gstepken@googlemail.com> wrote:
I always thought, the IMAGE *is* already an OO database!??
Yes, storing all sources in image should be also possible. The only problem with it, if your image crashes, you losing everything you did without chance of restoring it. That's why storing sources externally is better idea, at least from safety point of view. But again, it should be possible to choose where to store sources, not like today, when you have only .source and .changes.
Guido Stepken
Am 02.11.2011 um 15:27 schrieb Igor Stasenko <siguctua@gmail.com>:
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.
-- Best regards, Igor Stasenko.
We manage our source code with Monticello and I have never had to use the .changes file to get my code back. As I've said before: as far as I'm concerned, .sources and .changes have outlived their usefulness (not sure about the android and iPhone ports though. There might be an advantage regarding memory / disk space?) Max On 03.11.2011, at 15:08, Igor Stasenko wrote:
On 3 November 2011 12:57, Guido Stepken <gstepken@googlemail.com> wrote:
I always thought, the IMAGE *is* already an OO database!??
Yes, storing all sources in image should be also possible. The only problem with it, if your image crashes, you losing everything you did without chance of restoring it. That's why storing sources externally is better idea, at least from safety point of view.
But again, it should be possible to choose where to store sources, not like today, when you have only .source and .changes.
Guido Stepken
Am 02.11.2011 um 15:27 schrieb Igor Stasenko <siguctua@gmail.com>:
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.
-- Best regards, Igor Stasenko.
On 3 November 2011 14:41, Max Leske <maxleske@gmail.com> wrote:
We manage our source code with Monticello and I have never had to use the .changes file to get my code back. As I've said before: as far as I'm concerned, .sources and .changes have outlived their usefulness (not sure about the android and iPhone ports though. There might be an advantage regarding memory / disk space?)
I'm tempted to say that if you've never had to use your .changes file to recover, you're not working hard enough :) Even without doing extra tricky things, consider your image open on your laptop. You shut the lid, having realised your train's just about to arrive at your stop. You get to where you're going and your laptop's decided to switch off. (Or your laptop battery runs flat.) Your .changes file lets you recover your work. frank
Max
On 03.11.2011, at 15:08, Igor Stasenko wrote:
On 3 November 2011 12:57, Guido Stepken <gstepken@googlemail.com> wrote:
I always thought, the IMAGE *is* already an OO database!??
Yes, storing all sources in image should be also possible. The only problem with it, if your image crashes, you losing everything you did without chance of restoring it. That's why storing sources externally is better idea, at least from safety point of view.
But again, it should be possible to choose where to store sources, not like today, when you have only .source and .changes.
Guido Stepken
Am 02.11.2011 um 15:27 schrieb Igor Stasenko <siguctua@gmail.com>:
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.
-- Best regards, Igor Stasenko.
Frank Shearar-3 wrote:
I'm tempted to say that if you've never had to use your .changes file to recover, you're not working hard enough :)
Oh my, how my *ss has been saved by the .changes file. Especially while doing dangerous but important things (e.g testing bleeding edge cog vms). I can't count the hours... -- View this message in context: http://forum.world.st/Brainstorming-on-the-roadmap-for-first-Pharo-Consortiu... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
:-D I said: "In MY opinion" Ok, so the .changes file serves as a backup. But shouldn't the file be optional? e.g. the source code is in the image and changes are backed up to an extra file to guard against crashes. But I think, the image should not depend on that file. Does this make more sense? Max On 03.11.2011, at 16:12, Sean P. DeNigris wrote:
Frank Shearar-3 wrote:
I'm tempted to say that if you've never had to use your .changes file to recover, you're not working hard enough :)
Oh my, how my *ss has been saved by the .changes file. Especially while doing dangerous but important things (e.g testing bleeding edge cog vms). I can't count the hours...
-- View this message in context: http://forum.world.st/Brainstorming-on-the-roadmap-for-first-Pharo-Consortiu... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On 3 November 2011 17:16, Max Leske <maxleske@gmail.com> wrote:
:-D I said: "In MY opinion"
Ok, so the .changes file serves as a backup. But shouldn't the file be optional? e.g. the source code is in the image and changes are backed up to an extra file to guard against crashes. But I think, the image should not depend on that file. Does this make more sense?
It is.
Max
On 03.11.2011, at 16:12, Sean P. DeNigris wrote:
Frank Shearar-3 wrote:
I'm tempted to say that if you've never had to use your .changes file to recover, you're not working hard enough :)
Oh my, how my *ss has been saved by the .changes file. Especially while doing dangerous but important things (e.g testing bleeding edge cog vms). I can't count the hours...
-- View this message in context: http://forum.world.st/Brainstorming-on-the-roadmap-for-first-Pharo-Consortiu... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko.
Hi Guido--
I always thought, the IMAGE *is* already an OO database!??
Yes! Naiad, Spoon's history system, stores source code in a dedicated second image, via remote messaging. That image snapshots itself after every source code addition, and can provide all the crash recovery services that the changes file did. For more info, please see http://netjam.org/spoon/naiad/. -C -- Craig Latta www.netjam.org/resume +31 6 2757 7177 + 1 415 287 3547
Yes this is a long overdue. We will start another pass on it with nick in a week. So we will see: we want to have all the compilation chain to work in an environment. Stef
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
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
participants (16)
-
Ben Coman -
Benjamin -
Craig Latta -
Eliot Miranda -
Esteban Lorenzano -
Frank Shearar -
Guido Stepken -
Igor Stasenko -
Luc Fabresse -
Mariano Martinez Peck -
Max Leske -
Norbert Hartl -
Noury Bouraqadi -
Schwab,Wilhelm K -
Sean P. DeNigris -
Stéphane Ducasse