seaside-dev June 2014

seaside-dev@lists.squeakfoundation.org

12 participants
27 discussions

"Bootstrap" project for Seaside with separated Magritte support in a new project "BootstrapMagritte" on STHub
by Torsten Bergmann 16 Jul '18

16 Jul '18

Hi, The bundling with magritte polluted the repo and the Bootstrap project with stuff that was not really needed for "Seaside + Bootstrap" only. Also a "Bootstrap-Demo" package appeared that was more a demo for magritte than for Bootstrap. Since there already was an "Bootstrap-Examples" package this added more confusion (at least on my side). I now took action and cleaned up the Bootstrap project again to remove the magritte stuff. If one wants to to use Bootstrap with Seaside he does not necessarily have to go the Magritte path, so IMHO this was necessary. The magritte stuff for Bootstrap is now hosted as an own separate project on STHub which would also help to see to which part code additions really belong. As a result: ============ 1. The Bootstrap project now again only contains and loads the initial three packages: - Bootstrap-Core - Bootstrap-Tests-Core - Bootstrap-Examples assembled by the known ConfigurationOfBootstrap 2. The Magritte support on top of Bootstrap is now separated in an own project to avoid too much mixin. See "BootstrapMagritte" on SmalltalkHub. The new repo "http://smalltalkhub.com/#!/~TorstenBergmann/BootstrapMagritte" has the same commiters as the old one, so feel free to continue with your work. This project includes two packages: - Bootstrap-Magritte-Core (former Bootstrap-Magritte) - Bootstrap-Magritte-Examples (former Bootstrap-Demo) assembled by a new ConfigurationOfBootstrapMagritte for this particular project 3. The Bootstrap/ConfigurationOfBootstrap is now available as - a release version 0.4.0 for Seaside 3.0.9 - a release version 0.5.0 for Seaside 3.0.10 - a release version 0.6.0 for Seaside 3.1.0 (#stable) - a development version 0.7.0 for Seaside 3.1.0 for new stuff 4. The CI for Bootstrap is green for Pharo 2.0 and now also Pharo 3.0 5. The config browser is updated for Pharo 2.0 and Pharo 3.0 with the "Bootstrap" package So you can now also open a fresh Pharo 3.0 image, open World menu -> Configuration Browser to load "Bootstrap". Then run ZnZincServerAdaptor startOn: 8080 and start coding your web application with the latest Seaside 3.1.0. Next steps: Setting up a CI for the new project "BootstrapMagritte"/ConfigurationOfBootstrapMagritte Have fun! Bye Torsten

3 7

Re: [Pharo-dev] Versioner
by Diego Lont 30 Jun '14

30 Jun '14

Hi Christophe, > Hi Diego, > > Le 30 juin 2014 à 09:23, Diego Lont a écrit : > >> I am very happy that versioner is being built. We need more and better software configuration tools, and versioner will make our life easier. That being said, I am getting a bit nervous about how versioner is released. It should aim to improve the way people can work, and not to create a single workflow for all people working on pharo projects. I hope my fears are unfounded. > > You're right, Versionner enforces a single workflow. We tried to do a simple tool that can fit most people and very easy to use. Versionner is far from perfect but allows to easily manage project dependencies and release for a "classical" workflow. There are also some known limitations (e.g., no support of platform-specific sections). > Versionner does not aim that ALL people use a single workfow but tries to provide guidelines. If one needs another workflow, it is possible by using Metacello directly. If needed, we can also add features to Versionner. It may be done from feedbacks. > To summarize, it is not "One Ring to rule them all" but rather one tool to fit more needs and make configuration management easy. That is exactly my point. But Stef currently tries to enforce this workflow of working to Moose. And since this workflow will not work well for Moose (because of the demands on the process), I object to this. >> Within the Pharo community we have at least 3 different workflows: >> A. For Pharo core, we have a pharo inbox, where suggested fixes for reported bugs are put. These fixes are reviewed and, if accepted, integrated into Pharo. This ensures that the changes in Pharo hold (most of the time) to quite some quality standards. > It is the same workflow that GitHub favors: you fork the code, do your changes and provide a pull request that will be accepted or not. It works quite well. >> B. For the “cross-platform” projects (Grease, Seaside, Magritte, etc.) all suggested fixes are put in the main repository on smalltalkhub. The fixes are, after review and tests, released by putting them in a “released” version of the configuration. Since not all fixes should be in all versions, and sometimes only concern a certain platform, the process for Pharo core would not work: releasing fixes are more complex because of the cross-platform issues. > I don't see your point here. What is really different except that you don't have an inbox (some kind of dedicated branch)? Instead, you publish in the same repository, creating new branches. >> C. For the “moose” projects all suggested fixes are put in the main repository and are accepted by default. Since most projects evolve very fast, quality assurance is done afterwards, by submitting bug fixes. > Here, there is no review, ok. Your response shows that I have not made my point well. I wanted to point out that we need different workflows because of the different demands. A workflow is more than only a tool, but starts with people building something and ends with people using something. And you point out that versioner has one workflow implemented, and therefor will not be applicable to all projects. A. For pharo core all projects are included in pharo. The number of external influences (VM, plugins) is very limited. It works here to have no configuration at all, since there is only 1 release-branch: the current one. And since the file server creates a version of each build, we can always go back to a specific build. Quality is very important to pharo as a lot of users depend on a good working pharo. B. For the “cross-platform” projects this workflow is not sufficient, because there are much more external influences. So here we use the configurations to manage the releases. And the complexity of the configuration of Seaside shows this is a very complex thing to do. This complexity is not from Metacello. Metacello allows us to do a decent job here for the supported platforms. For the unsupported platforms there is some additional manual work involved, with all risks to this. The complexity here stems from the Software Configuration challenges Seaside faces. A simple inbox won’t do the job for us. Quality here is also very important as a lot of users depend on a good working Seaside. Also there are more demands on reproducibility, as there are quite some systems depending on Seaside that should function 24/7. C. For the “moose” projects, we have a few advantages above the cross-platform projects, and a few disadvantages: + Moose only needs to work for pharo. So we can cut out a lot of platform specific junk. Some projects are suited for multiple platforms, but not for the amount of platform Seaside should work on. + There are far less projects depending on Moose. Most of them are integrated, so tests will automatically be fired. And the projects that do depend on Moose usually do not have run 24/7. - Moose depends on more projects then Seaside. To create an exact version is therefor much harder. - A large part of the Moose bugs comes from the change rate of the projects Moose depends on. Pharo has a very drastic strategy to improve its architecture. This causes quite some maintenance work. So that there is no review is not the point. The point is that because of these different demands we need to accept a lower quality standard for moose. This lower quality standard is maybe undesirable, but is not easily improved. Having no review is a consequence of this, not the cause. If we want to improve this quality standard, better SCM tools will not suffice. On the other hand, this lower quality standard has so far worked for Moose, as there are less people who depend on Moose. Regards, Diego

1 0

Versioner
by Diego Lont 30 Jun '14

30 Jun '14

I am afraid this mail is going to be too long, but I feel it needs to be written. I will start with the conclusion, so you can skip the mail if you feel it does not interest you. Please keep the discussion on the Moose list, as there the discussion was started. I am very happy that versioner is being built. We need more and better software configuration tools, and versioner will make our life easier. That being said, I am getting a bit nervous about how versioner is released. It should aim to improve the way people can work, and not to create a single workflow for all people working on pharo projects. I hope my fears are unfounded. Software configuration management (SCM) is in my opinion an undervalued topic within the software world. One cannot find very many good books on them, and I am afraid this lack of knowledge shows in the way people go around with their SCM. So I would like to write down some observations of the SCM processes in Pharo that I believe we should keep in mind. The main target of SCM is to keep the impact of changes as minimal as possible. Good SCM allows all people working on a certain project, to make their changes, without causing trouble for other project members and people using this project. Open source projects are (in SCM terms) rather complex, as they involve a lot of people, including some people we do not know. 1. One of the best things of Metacello is that it does not require you to follow a certain workflow. It is very flexible and supports a large range of possible workflows. Within the Pharo community we have at least 3 different workflows: A. For Pharo core, we have a pharo inbox, where suggested fixes for reported bugs are put. These fixes are reviewed and, if accepted, integrated into Pharo. This ensures that the changes in Pharo hold (most of the time) to quite some quality standards. B. For the “cross-platform” projects (Grease, Seaside, Magritte, etc.) all suggested fixes are put in the main repository on smalltalkhub. The fixes are, after review and tests, released by putting them in a “released” version of the configuration. Since not all fixes should be in all versions, and sometimes only concern a certain platform, the process for Pharo core would not work: releasing fixes are more complex because of the cross-platform issues. C. For the “moose” projects all suggested fixes are put in the main repository and are accepted by default. Since most projects evolve very fast, quality assurance is done afterwards, by submitting bug fixes. I can say a lot about why I believe these workflows are appropriate for their different projects, but the point I am trying to make here, is that these workflows have come to existence because of the different demands on them. And to stress my point about the flexibility (thank you Dale): When there was a problem with the workflow in the cross platform projects, I could find a solution (using releases) that Metacello supported. 2. Unfortunately Metacello does not have a good UI. And for large configurations like Seaside, it is a lot of work to keep them maintained. I dream of a tool that acts as a UI for Metacello: this tool is flexible as Metacello, while making the simple things real easy (hitting a button and done). Does versioner aim to do this? 3. I always get very nervous when someone says: They do it like this, and that works very well for them. So we should do that too. I do not believe that is always a good idea. The conclusion should be a question: Can we use that too? And now I cannot find the mail about the java SCM practice, but I do not think we can apply it to all our processes ... 4. Modularity is very important. Also for performing good SCM. And yes, we lack sufficient modularity in Moose. It should be better. I.e. because of the lack of modularity, it is sometimes hard to distinguish between where the change needs to be put in. So there is no clear group to point out who should accept the changes. So this is also an SCM problem. Cleaning up the configuration will help here very much. Thank you Steff for the good work here. And maybe you also have a point that the people working on Moose should have more focus on keeping things modular, because it makes the system better maintainable in a lot of ways. 5. Forking things will only make SCM worse, as it adds a complexity. So I very much hope we can come to an agreement how the process works, without resorting to drastic measures. Regards, Diego

1 0

Sport 2.34
by Stephan Eggermont 25 Jun '14

25 Jun '14

I made some changes to use Sport 2.34, which is Pharo 4 enabled. Testing it was interrupted when the Zinc repository was broken. Stephan

1 0

Pharo 4 build: Please add us to Sport
by Stephan Eggermont 25 Jun '14

25 Jun '14

Hi Johan, can you add Diego and me to Sport? Here is a sport configuration that should get rid of a few test failures. I've also updated Grease so Magritte3 release30 is now green

2 1

Re: [Seaside-dev] Sprint at ESUG
by Johan Brichau 20 Jun '14

20 Jun '14

I just booked my travel and will be there on friday and saturday (leaving saturday end of the afternoon). Johan > On 25 May 2014, at 22:46, Philippe Marschall <philippe.marschall(a)gmail.com> wrote: > >> Hi >> >> We're planning to do a sprint this year as well (Friday, Saturday, >> maybe part of Sunday) but we don't have confirmation for a location >> yet. >> >> Cheers >> Philippe >> _______________________________________________ >> seaside-dev mailing list >> seaside-dev(a)lists.squeakfoundation.org >> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev >

3 2

Re: [Seaside Issues] Issue 797 in seaside: Seaside-JSON-Core extends BlockClosure but BlockClosure is not a portable class
by John O'Keefe 17 Jun '14

17 Jun '14

Yes, it just takes moving the extension to a platform - specific package. I know how to do that for Pharo, but I'm clueless what to do for Gemstone. On Jun 16, 2014 4:48 PM, <seaside(a)googlecode.com> wrote: > > Comment #1 on issue 797 by jo...(a)yesplan.be: Seaside-JSON-Core extends > BlockClosure but BlockClosure is not a portable class > http://code.google.com/p/seaside/issues/detail?id=797 > > I guess this is a straightforward request and change. We just need to mind > updating the Gemstone JSON package. There is a testcase covering this > method, so it will pop up as broken when porting. > > -- > You received this message because this project is configured to send all > issue notifications to this address. > You may adjust your notification preferences at: > https://code.google.com/hosting/settings > > _______________________________________________ > issues mailing list > To unsubscribe, email issues-leave(a)lists.seaside.st > http://lists.seaside.st/listinfo/issues >

2 1

Re: Pier 3 image editor fails with MNU: JQTabs>>onSelect:
by Diego Lont 16 Jun '14

16 Jun '14

Hi John, Thanks for spotting this and providing a fix. I could not find your user, so I committed your fix myself. I also updated the configuration of Seaside, such that version 3.1.2 of Seaside3 now contains this fix. As this is the development version and Pier depends on the stable (released) version, it will take a bit before this fix is actually included in the build you mention. Cheers, Diego On 15 Jun 2014, at 21:40, John Borden <jborden23(a)mac.com> wrote: > The latest image from https://ci.inria.fr/pharo-contribution/job/Pier3Addons/PHARO=30,VERSION=rel… starts fine, but when editing a page it fails with the error: > > Contents: > MessageNotUnderstood: JQTabs>>onSelect: > > Your request could not be completed. An exception occurred. > > Attached is a fix, would anyone have access to add write permissions for me to http://smalltalkhub.com/mc/Seaside/Seaside31/main/ ? > > > > Thanks, > > John > > <JQuery-UI-JohnCBorden.90.mcz>_______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki

2 3

Fake Guru Hamid Arabnia and bogus WORLDCOMP and CSCI
by jermy23＠hushmail.com 14 Jun '14

14 Jun '14

Fake Guru Hamid Arabnia and bogus WORLDCOMP and CSCI If you have any thought of attending the world’s biggest fake or bogus conference in computer science, WORLDCOMP http://www.world-academy-of-science.org you must visit any websites below https://sites.google.com/site/worlddump1 or https://sites.google.com/site/dumpconf https://sites.google.com/site/moneycomp1 https://sites.google.com/site/worlddump4 The organizer of this conference is Hamid Arabnia http://www.cs.uga.edu/~hra a professor from University of Georgia, USA. The primary goal of this conference is to collect registration fee by accepting all submitted papers. Several fake papers were published in the conference proceedings. He already earned millions of dollars from the registration fee and is using part of the money for anti-Christmas greetings campaign. http://worldcomp-fake-bogus.blogspot.com has additional information on this campaign. He recently started another new conference CSCI due to his hunger for money http://www.americancse.org Hamid Arabnia failed to reveal the reviews and reviewers' information for all the papers he received, despite repeated requests and challenges. The reason for his failure is there were no reviews and reviewers and he just cheated the research community for more than a decade by announcing that each draft paper is reviewed by two experts. We challenge him to publish these details at the conference website. Where are these experts? Where are these reviews? He pays tens of thousands of dollars and brings keynote speakers and project his conference as a great one. He lists the names of current and former keynote speakers on the front page of the conference and use those names as baits to attract paper submissions from innocent researchers. He always conducts the conferences in the “sin city” to attract people who prefer “other” activities. DBLP stopped indexing these conferences since 2011 and displayed an explicit message; The DBLP Advisory Board decided to discontinue indexing of this conference series. Visit http://www.informatik.uni-trier.de/~ley/db/conf/biocomp/index.html as a sample. He was forced to remove his name, the university of Georgia name, and university of Georgia email address from the conference’s contact page because the University has banned him from doing that. He is running the conference behind the scenes and there is no coordinator or general chair listed for this conference. Almost every week (until the conference date is so close), Hamid Arabnia updates the conference website with things like this: You are invited to submit a "Late Breaking Paper", "Position Paper", "Abstract/Poster Paper" or “Abstract of Thesis or Dissertation” for consideration, etc. He wants more papers because each paper generates around 500 US dollars in to his pocket. Additional information on this conference bogus conference is available by searching internet using the keywords worldcomp fake or Hamid Arabnia fake Apologies for posting to multiple mailing lists. Spreading the word is the only way to stop this conference from cheating innocent researchers.

1 0

Re: missing methods in GemStone Grease packages
by Paul DeBruicker 11 Jun '14

11 Jun '14

mmm scratch that. I had my versions wrong. 'GRPlatform current seasideVersion' reports its Seaside 3.1.0 ‘GRPlatform current versionString’ reports 1.0.7 (Gemstone) So maybe I should update rather than upload my fixes. On Jun 10, 2014, at 10:28 PM, Paul DeBruicker <paul(a)getcooperation.com> wrote: > Hi - > > In Seaside 3.1.1, Glass 1.0b9.1 & Gemstone 3.1.0.6. these methods are missing, and used by my stuff. > > > GRGemStonePlatform>>#writeCharacterStreamOn: > ^ AnsiWriteStream on: aString > > > GRCodecStream>>#reset > stream reset > > > #writeCharacterStreamOn: is sent in > > WABufferedResponse class>>new > WAComboResponse class>>external: > WAServerAdaptor>>responseFor: > > > #reset is sent in WABufferedResponse>>#resetIfPossible and possibly other places. > > > > > These implementation seems to work for my needs. Should I upload a version that has them?

2 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

seaside-dev June 2014