[squeak-dev] The future of Squeak & Pharo (was Re: [Pharo-project] [ANN] Pharo MIT license clean)
Locked
123456
... 10
123456
... 10
Re: [squeak-dev] The future of Squeak & Pharo
 
|
> Even disregarding what the Pharo people would think about the idea,
> doesn't that argument go both ways? As in "given that Pharo already > forked, Etoys can now be reintegrated to Squeak"? seems even more logical to me, indeed. Stef |
Re: [squeak-dev] The future of Squeak & Pharo
|
|
In reply to this post by Bert Freudenberg
On Sun, Jun 28, 2009 at 4:07 PM, Bert Freudenberg <[hidden email]> wrote:
Yes, but in my opinion, Etoys is too much "specific". Etoys is excellent, for what it is. But I don't think Squeak must be toys specific. It must be a good object oriented platform to build applications. Any of them: toys, enterprise, research, etc... I think in this way, Pharo is much more "generic" than Etoys. Something more similar to Squeak. Cheers, Mariano
|
|
|
In reply to this post by Klaus D. Witzel
Hey, this looks great! Care to explain more about what you are working
on? What are your goals? I really like the fact that it is loadable into three of the forks. ;-) Cheers, Bernhard Am 28.06.2009 um 20:54 schrieb Klaus D. Witzel: > On Sun, 28 Jun 2009 19:28:50 +0200, Philippe Marschall wrote: > > ... >> And don't get me "but we need it for fonts". The only way to get nice >> fonts in Squeak is to avoid it and do it in C with char*. > > Can you see the attached (?) : a platform font, displaying #('Basic > Latin' 'Cyrillic'), using standard Squeak libs and VM, its Smalltalk > code loadable into Cuis, Pharo and Squeak. > > No line of C nor char*, other than what is already in the VM and its > plugins (and currently _nothing_ optimized). > > ? > >> Cheers >> Philippe >> > > > -- > "If at first, the idea is not absurd, then there is no hope for it". > Albert Einstein<TestFontRendering.png> |
|
|
In reply to this post by keith1y
Hi Keith,
As Juan, I would also like to know what you are referring to? Do you mean the mission statement of the Squeak Oversight Board? http://squeakboard.wordpress.com/our-mission/ I think it is a very good mission statement. But except for perhaps "integrating contributions from collaborating groups (for example, Pharo, Etoys, and Croquet)" I see little with regards to content. (This is no critique at all, by the way!) Or are you referring to something else? Cheers, Bernhard Am 28.06.2009 um 19:05 schrieb Keith Hodges:
|
Re: [squeak-dev] The future of Squeak & Pharo
|
|
In reply to this post by Bert Freudenberg
On Sun, Jun 28, 2009 at 09:07:45PM +0200, Bert Freudenberg wrote:
> > On 28.06.2009, at 20:53, Randal L. Schwartz wrote: > > >>>>>>"Colin" == Colin Putney <[hidden email]> writes: > > > >Colin> IMHO, Squeak.org needs to either recommit to Etoys and education as its > >Colin> primary mission, or break compatibility and become a general Smalltalk > >Colin> platform for a variety of applications. This suggests a merger with > >Colin> either Squeakland or Pharo, but even without merging, Squeak.org can > >Colin> get its mojo back if it chooses an identity. > > > >At this point, I'd be leaning back towards squeak central reintegrating Pharo, > >given that Etoys already forked. > > Even disregarding what the Pharo people would think about the idea, > doesn't that argument go both ways? As in "given that Pharo already > forked, Etoys can now be reintegrated to Squeak"? Integrating Etoys back into Squeak is a good idea, and right now would be a good time to do it. I don't have any personal involvement with Etoys, but it seems like the Right Thing To Do in the interest of maximizing the total worldwide supply of good karma. Reintegrating Pharo might be a good thing to do, but it seems premature to be worrying about it now. Dave |
[squeak-dev] Re: The future of Squeak & Pharo
|
|
In reply to this post by Ian Trudel-2
Ian Trudel pravi:
> Göran Krampe: >> Not sure what you mean there. > > Squeak is hardly approachable to newcomers (either seasoned > programmers or simple new ones). Gaining popularity explicitly means > to have newcomers. It's not possible if they can't understand what's > going on. > >> Personally I like the colors. I also don't equal "normal" with >> "professional". But such is taste! > > We could certainly debate on tastes but it's perfectly fine that you > like the current colour scheme. However, you're not alone using Squeak > and we have to consider other tastes. > I just mean something approachable (normal look-and-feel), where > people will feel comfortable from the day they start using Squeak > through every other following days. > A professional look-and-feel is probably more about simplicity and > usability. It doesn't need to have colours by truck load. Something > that one can spend countless hours looking at without eyes popping out > of their sockets. And it's about everything... for example, Squeak has > these childish window buttons and so on... it's NOT that cool, far > from being trendy. Why would we get stubborn to keep such things? It > looks like a toy, Squeak sometimes feels like a toy. When I squeeze > Squeak, it squeaks. Just saying... =) I completely agree with Ian here. If Squeak wants to be considered for serious development, but also to attract developers from other communities and newcomers, it must have the look&feel which is close to theirs. This not mean that it must be the same, no, just that it follows the established look&feel standards elsewhere. Current Squeak is far away from that, while Pharo is marching well into a more standard look&feel direction. This is actually one of main reasons I'm attracted to Pharo. Also because they listen to such proposals! But this don't mean that EToys can stay more colorful, no, let it be on top of that more "traditionally professional" base. Why to mix two so different audiences into one image? Janko > And, unless some of us are graphic designers, why not just focus on > something simple, usable and approachable? That's definitively not out > of reach. > >> Note that talking about what we "need" and what other people "want" is not >> really that fruitful. We get what we *do*, or in other words - if someone >> feels it is important enough to spend time on it - it will get done. Noone >> works on something because *someone else* told him to. > > It seems to me that we are crying for direction as a community. Squeak > seems to be lost. Consequently, need, want, do, etc... it's just not > happening. Don't get me wrong, but it's just that you make it sounds > like everything can be done without a plan. And some of the things we > could want requires a lot of work hours and man power. It's not going > to happen overnight. > >>> requirements of my distributors, which makes it overly challenging for >>> me to consider Squeak as our platform of development. >> Elaborate? > > Please, Igor and I have talked a little bit about this. He will > certainly bring that on board's table. Anyway, Göran, I hope to be > able to share a complete list at later time. I am not done reviewing > the requirements. It's also challenging to know the status of projects > in Squeak and what has to be done. > > >>> Squeak doesn't need a killer app. It needs to be spruced up and put >>> back on track. Honey moon is over, it's time to get real. >> Hehe, I really don't agree. :) >> >> Squeak *is* real. We already have our killer app (Seaside). We do need to >> clean shit up though (and I am not talking about UI primarily) and get the >> improvement process working. Currently Squeak.org is getting smashed (again, >> I don't have hard numbers, but I think I am right) by Pharo when it comes to >> hard, concrete, nitty gritt work getting done. > > Squeak has a killer app named Seaside. > Ruby has a killer app named Ruby On Rails. > Both are web frameworks, which kills which? > > It doesn't really matter. It's not even about merits. Ruby is still > more approachable language and better documented. And I find it almost > amusing to have a killer app for the web, when one of the strength of > Squeak is multimedia. No, no, I am not trying to flame war here... > just trying to expose few things in order that we can openly discuss > about them. > > Whether you agree or not, Squeak doesn't seem to gain in popularity > and people are flocking out to other forks. That means Squeak is doing > something wrong. Wrong enough to overcome all the "done right". =) > > Regards, > Ian > -- Janko Mivšek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si |
Re: [squeak-dev] The future of Squeak & Pharo
|
|
In reply to this post by Bert Freudenberg
2009/6/28 Bert Freudenberg <[hidden email]>:
> Even disregarding what the Pharo people would think about the idea, doesn't > that argument go both ways? As in "given that Pharo already forked, Etoys > can now be reintegrated to Squeak"? As far as I am concerned, I am not and never been interested in Etoys. I managed to avoid it altogether for the years ever since I begun to use Squeak. I'd rather prefer not have Etoys merged into Squeak. Ian. -- http://mecenia.blogspot.com/ |
|
|
In reply to this post by Ian Trudel-2
Em 28-06-2009 15:10, Ian Trudel escreveu:
(...)I would like to add that currently much of Linux development has corporate support. Without that linux would be dead or would be in the same instance as, let's say, FreeBSD. That doesn't mean that corporations are telling which direction linux must follow. Linux is only the most obvious example. But I don't like to look at Squeak only as a toy platform that some MSc and PhD students can use to develop their works. I guess that people who's supporting their packages since old releases will agree with me. Besides, most people in the smalltalk communities ask the question: why Java did it while smalltalk didn't? And the answers are all around: Java had documentation from day 0. Java was really cross platform from day 0. Java was highly standardized. Java didn't oversaw day to day requirements as internationalization and comprehensive file and network support... And now the list of languages that are doing while smalltalk is spinning around is growing with Python, Ruby and other languages/environments. And I feel dismay when I see that even traditional smalltalk distributions (like Cincom VW) are loosing spin. In short: money is not a bad thing. It allows development. Even when we are in academic environments money help to justify research and development projects. Want another example? SWI-Prolog. But lack of money can be a problem. How many bright smalltalk researchers cannot work as much as they need/want to because they're involved in all sort of "more important, more immediate" projects? How many people left smalltalk development (not only squeak) to work in "more profitable areas"? Even people as Mr. Ungar and Mr. Kay and others had to stop/reduce participating strongly in Squeak committee due to other professional duties. That signs that for their current employers Squeak is not important enough to justify time employed in deciding its present and future. When I was younger, working at university, I had this prejudice against money and "corporate support" and believed strongly in the obligation of State to financially support projects that would never ever pay themselves. That the "market" was controlled by a bunch of unlettered execs refractory to changes. Life proved that this prejudice didn't make me any good. CdAB |
|
|
In reply to this post by Göran Krampe
Am 28.06.2009 um 12:23 schrieb Göran Krampe:
> Even the squeak-dev list is quieting down and that is a bad sign. Would that be a good time then to merge back some of the many Squeak mailing lists? Most of them have very low traffic anyway. IMO having so many mailing lists leads to increased fragmentation of the community. It often happened to me that I found out too late about a new mailing list. Now I miss many relevant mails in my archive and ask questions which were answered already on a list I had not subscribed. What do others think? Cheers, Bernhard |
Re: [squeak-dev] Merge mailing lists? (was The future of Squeak & Pharo (was Re: [Pharo-project] [ANN] Pharo MIT license clean))
|
|
Great idea, Bernhard. I vote for it.
If my vote count for something. o_O Ian. 2009/6/28 Bernhard Pieber <[hidden email]>: > Am 28.06.2009 um 12:23 schrieb Göran Krampe: >> >> Even the squeak-dev list is quieting down and that is a bad sign. > > Would that be a good time then to merge back some of the many Squeak mailing > lists? Most of them have very low traffic anyway. IMO having so many mailing > lists leads to increased fragmentation of the community. It often happened > to me that I found out too late about a new mailing list. Now I miss many > relevant mails in my archive and ask questions which were answered already > on a list I had not subscribed. What do others think? > > Cheers, > Bernhard > -- http://mecenia.blogspot.com/ |
Re: [squeak-dev] I18-23N [was: The future of Squeak & Pharo ... etc]
|
|
In reply to this post by Klaus D. Witzel
2009/6/28 Klaus D. Witzel <[hidden email]>:
> On Sun, 28 Jun 2009 19:35:45 +0200, Philippe Marschall wrote: > >> 2009/6/28 Klaus D. Witzel : >>> >>> On Sun, 28 Jun 2009 19:05:30 +0200, Ian Trudel wrote: >>> >>>> I like your ideas, Casimiro. And a lot of boring work, as you would >>>> call, but I call it maintenance, has to be done. Internationalization >>>> is among the point that prevents me to use Squeak. >>> >>> Ian, would it be possible you send me a list of what things _you_ need >>> for >>> internationalization. That would be very interesting in a current >>> project. >> >> Oh, I forgot the usual things. Unicode normalization, collators, date, >> number and currency formatting, unicode regexes. > > Don't get me wrong now: I know you're talking about your framework, No, not at all. These are more a 21st century programming language "features" that just "have to be there". > can you > point me to more specific locations (release/version, class name, method > name) or so? No. AFAIK some of this stuff in on the roadmap for VW 7.7. http://site.icu-project.org/ This is what most PHP frameworks use these days and you feel kinda 2nd class compared to them if you don't provide it. >> Basically what ICU does. > > Assume that some other project has something new (in a recent .image on a > Squeak VM). Not that I know of. > How can your stuff be tested with it? Would it be necessary to refactor your > app, or can a project man like me do this and that, test this and that (!) ? There isn't any of the stuff. That's just some of the things that I consider missing in Squeak in the l10n area. Cheers Philippe |
[squeak-dev] Re: Sq font rendering [was: The future of Squeak & Pharo ... etc]
|
|
In reply to this post by bpi
On Sun, 28 Jun 2009 21:21:28 +0200, Bernhard Pieber wrote:
> Hey, this looks great! :) > Care to explain more about what you are working on? What are your goals? > I really like the fact that it is loadable into three of the forks. ;-) three of the forks: a "simple" side effect by the very developer who's responsible for the rendering part, he prefers subclassing of existing Smalltalk libs. BTW: Cuis has no WideString but will probably be the fastest of the three. goals: render _every_ glyph that is in _any_ modern (Unicode) platform font; make fonts offline and online usable, especially on small devices if needed, on demand (by end user). working on: three parts 1) fonts/glyphs without new plugins/VM support; 2) glyphs "char" map visualization (for end user support); 3) glyph composition (for complicated scripts which need more than one glyph per "character" location). Have an application in mind which we can add for doing tests? /Klaus > Cheers, > Bernhard > -- "If at first, the idea is not absurd, then there is no hope for it". Albert Einstein |
[squeak-dev] Re: I18-23N [was: The future of Squeak & Pharo ... etc]
|
|
In reply to this post by Philippe Marschall
On Sun, 28 Jun 2009 21:49:07 +0200, Philippe Marschall wrote:
> 2009/6/28 Klaus D. Witzel : >> On Sun, 28 Jun 2009 19:35:45 +0200, Philippe Marschall wrote: >> >>> 2009/6/28 Klaus D. Witzel : >>>> >>>> On Sun, 28 Jun 2009 19:05:30 +0200, Ian Trudel wrote: >>>> >>>>> I like your ideas, Casimiro. And a lot of boring work, as you would >>>>> call, but I call it maintenance, has to be done. Internationalization >>>>> is among the point that prevents me to use Squeak. >>>> >>>> Ian, would it be possible you send me a list of what things _you_ need >>>> for >>>> internationalization. That would be very interesting in a current >>>> project. >>> >>> Oh, I forgot the usual things. Unicode normalization, collators, date, >>> number and currency formatting, unicode regexes. >> >> Don't get me wrong now: I know you're talking about your framework, > > No, not at all. These are more a 21st century programming language > "features" that just "have to be there". I do not care :) this is like: Ma get me that car over there. Instead, I want to test/and or integrate, this is why I asked. >> can you >> point me to more specific locations (release/version, class name, method >> name) or so? > > No. AFAIK some of this stuff in on the roadmap for VW 7.7. > > http://site.icu-project.org/ > This is what most PHP frameworks use these days and you feel kinda 2nd > class compared to them if you don't provide it. > >>> Basically what ICU does. >> >> Assume that some other project has something new (in a recent .image on >> a >> Squeak VM). > > Not that I know of. Can't you just follow the words "assume that, for the next line, that ...". >> How can your stuff be tested with it? Would it be necessary to refactor >> your >> app, or can a project man like me do this and that, test this and that >> (!) ? > > There isn't any of the stuff. I asked for existing apps who need it. If there is no need, how can I test adding I18-23 support? I think you got me wrong. > That's just some of the things that I > consider missing in Squeak in the l10n area. > > Cheers > Philippe > -- "If at first, the idea is not absurd, then there is no hope for it". Albert Einstein |
[squeak-dev] Re: The future of Squeak & Pharo
|
|
In reply to this post by Bert Freudenberg
Bert Freudenberg pravi:
> Randal L. Schwartz wrote: >> At this point, I'd be leaning back towards squeak central >> reintegrating Pharo, >> given that Etoys already forked. > Even disregarding what the Pharo people would think about the idea, > doesn't that argument go both ways? As in "given that Pharo already > forked, Etoys can now be reintegrated to Squeak"? Hardly. Pharo deals with lower levels than EToys, EToys works in top of that core, being Pharo or Squeak. That's why I see Randal's suggestion reasonable and a nice refinement of Göran's original "merge" idea. Then one should just adjust EToys on top, or I'm too naive and don't see some technical problem here? Best regards Janko -- Janko Mivšek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si |
|
|
In reply to this post by Klaus D. Witzel
Am 28.06.2009 um 21:50 schrieb Klaus D. Witzel: > BTW: Cuis has no WideString but will probably be the fastest of the > three. Sound great! Cuis looks very promising! > goals: render _every_ glyph that is in _any_ modern (Unicode) > platform font; make fonts offline and online usable, especially on > small devices if needed, on demand (by end user). Sounds cool. What do you mean by offline and online usable? > Have an application in mind which we can add for doing tests? I am thinking about a kind of a special purpose, offline replicating, non-web wiki, with something like CouchDB as the persistence layer. > "If at first, the idea is not absurd, then there is no hope for it". > Albert Einstein That quote probably fits my project. ;-) |
Re: [squeak-dev] Merge mailing lists? (was The future of Squeak & Pharo (was Re: [Pharo-project] [ANN] Pharo MIT license clean))
|
|
In reply to this post by Ian Trudel-2
On Sun, Jun 28, 2009 at 4:45 PM, Ian Trudel <[hidden email]> wrote: Great idea, Bernhard. I vote for it. Why don't you just subscribe to both mailing lists?
|
|
|
In reply to this post by Juan Vuletich-4
Dear Juan,
> Ok. So, what does that set of objectives and agenda say about: > - Backwards compatiblity We have had Installer, and LevelPlayingField for ages. The purpose of which is to make some compatability possible between different images, and ongoing changes to API's can be back ported to other images thus preserving backwards compatability, and providing forwards compatability where possible. We have more backwards and forwards compatibility now than we ever had before. The crux of the difference between squeak and pharo philosophies has been the issue of backwards compatability. > - Removal (or not) of stuff All tools we are using for 3.11 are not reliant upon a gui. This is explicitly because the stated goal has been for at least 3 years to work towards a kernel image, with which people can build up the custom image that they want. > - Addition (or not) of stuff The proposal is to have a range of deliverables for different goals, from minimal images to fully loaded images for testing. > - Modularity > - Any concrete statement (about the software, not the process!) so > people can know what to expect > ? This statement has been that 4.0 would be as 3.10 with minimal changes for relicencing purposes. 3.11 has been proposed as an image with minimal changes, that would be proof of concept for the new process. a) Readies the image for automated build and testing - i.e. release early and often will be properly possible at last b) Readies the image for our automated/open mantis integration for bug fixes c) Hopefully includes atomic loading for making radical changes to the image possible (i.e. new gui/compiler etc) d) Readies the image for future releases that are assembled by a selection of components, working to a design proposal rather than by an infinite set of incremental changes by one or two control freaks. (p.s. I need help someone to test and debug (c)) The actual "design" as to what 3.11 results in has been in the form of executable code for over a year, in the ss/Tasks repository. This is probably looking a bit stale now since I have been working on bob. > When was it approved by the community or the elected leadership? ages ago. http://installer.pbworks.com/Squeak311Proposal > Was there a decision process involving the community? http://installer.pbworks.com/Squeak311 Keith |
[squeak-dev] Re: Re: Sq font rendering [was: The future of Squeak & Pharo ... etc]
|
|
In reply to this post by bpi
On Sun, 28 Jun 2009 22:08:01 +0200, Bernhard Pieber wrote:
> > Am 28.06.2009 um 21:50 schrieb Klaus D. Witzel: >> BTW: Cuis has no WideString but will probably be the fastest of the >> three. > Sound great! Cuis looks very promising! > >> goals: render _every_ glyph that is in _any_ modern (Unicode) platform >> font; make fonts offline and online usable, especially on small devices >> if needed, on demand (by end user). > Sounds cool. What do you mean by offline and online usable? If a company/organization bought/licensed some special font, or the font is in public domain, and you don't want to install it on every PC or every device, then we can make it part of the Smalltalk .image file. >> Have an application in mind which we can add for doing tests? > I am thinking about a kind of a special purpose, offline replicating, > non-web wiki, with something like CouchDB as the persistence layer. If you would need support for any/mix of these scripts, - http://unicode.org/Public/UNIDATA/Blocks.txt then our font/glyph support can be interesting for you. >> "If at first, the idea is not absurd, then there is no hope for it". >> Albert Einstein > That quote probably fits my project. ;-) :) /Klaus |
|
|
In reply to this post by K. K. Subramaniam
I agree with what Juan and K. K. Subramaniam wrote. Squeak needs a goal, a statement what it is supposed to be. One thing I miss from the old days is the kitchen sink image. Neither Etoys nor Pharo have the goal for delivering such an image. So that could be a good raison d'être: Show what can be done with Squeak, and show what is done with Squeak. Something inclusive, a place for showing off all the cool, interesting, blue plane stuff, which is possible with such a dynamic environment. This attracted me to Squeak in the first place, and I think it still has the potential to attract newcomers.
I miss Connectors, MathMorphs, Alice, Games, ThingLab, Genie, Nebraska and all the other cool things that were once. But maybe it's just me. ;-) Thanks for your attention. Cheers, Bernhard Am 28.06.2009 um 20:02 schrieb K. K. Subramaniam:
Am 28.06.2009 um 16:08 schrieb Juan Vuletich:
Am 28.06.2009 um 14:57 schrieb Juan Vuletich:
|
Re: [squeak-dev] I18-23N [was: The future of Squeak & Pharo ... etc]
|
|
In reply to this post by Philippe Marschall
2009/6/28 Philippe Marschall <[hidden email]>:
> 2009/6/28 Klaus D. Witzel <[hidden email]>: >> On Sun, 28 Jun 2009 19:35:45 +0200, Philippe Marschall wrote: >> >>> 2009/6/28 Klaus D. Witzel : >>>> >>>> On Sun, 28 Jun 2009 19:05:30 +0200, Ian Trudel wrote: >>>> >>>>> I like your ideas, Casimiro. And a lot of boring work, as you would >>>>> call, but I call it maintenance, has to be done. Internationalization >>>>> is among the point that prevents me to use Squeak. >>>> >>>> Ian, would it be possible you send me a list of what things _you_ need >>>> for >>>> internationalization. That would be very interesting in a current >>>> project. >>> >>> Oh, I forgot the usual things. Unicode normalization, collators, date, >>> number and currency formatting, unicode regexes. >> >> Don't get me wrong now: I know you're talking about your framework, > > No, not at all. These are more a 21st century programming language > "features" that just "have to be there". > >> can you >> point me to more specific locations (release/version, class name, method >> name) or so? > > No. AFAIK some of this stuff in on the roadmap for VW 7.7. > > http://site.icu-project.org/ > This is what most PHP frameworks use these days and you feel kinda 2nd > class compared to them if you don't provide it. > That is very true. World become smaller and smaller. >>> Basically what ICU does. >> >> Assume that some other project has something new (in a recent .image on a >> Squeak VM). > > Not that I know of. > >> How can your stuff be tested with it? Would it be necessary to refactor your >> app, or can a project man like me do this and that, test this and that (!) ? > > There isn't any of the stuff. That's just some of the things that I > consider missing in Squeak in the l10n area. > > Cheers > Philippe > > -- Best regards, Igor Stasenko AKA sig. |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |