Pharo-dev
By thread
pharo-dev@lists.pharo.org
By month
Messages by month
- ----- 2026 -----
- July
- June
- May
- April
- March
- February
- January
- ----- 2025 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2024 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2023 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2022 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2021 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2020 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2019 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2018 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2017 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2016 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2015 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2014 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2013 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2012 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2011 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2010 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2009 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2008 -----
- December
- November
- October
- September
- August
- July
- June
- May
March 2016
- 716 messages
Re: [Pharo-dev] [pharo-project/pharo-core] 073848: 50662
by stepharo
Is this fixing the flickering and unselection deselection in spotter?
Le 26/3/16 11:08, GitHub a écrit :
> Moose
>
> http://files.pharo.org/image/50/50662.zip
March 26, 2016
Re: [Pharo-dev] Fwd: Squeak 5 on Raspberry Pi
by phil＠highoctane.be
On Sat, Mar 26, 2016 at 9:19 AM, stepharo <stepharo(a)free.fr> wrote:
>
> I want a clean and stable core.
>
>
> me too.
> Now you will not my core. Because there is no UI no announcement...
>
> The way Rubric and GT-Tools were pushed into the core was a mess.
>
>
> No I cannot let you to say that. I'm sorry. We spent 4 months cleaning
> Nautilus
> and Rubric is not optimal but we decided that forcing to adapt to Rubric
> was a good move
> for the next one. We did it to help
> - breakpoints
> - QA feedback
>
> Rubric was pushed in Pharo over the summer. So if we cannot change
> something as important that
> that more than 8 months before the release then we should better stop to
> do pharo.
> Because for Rubric ***I*** planned it in advance with a stabilisation
> phase.
> Now Pharo 50 got far too many new features
>
> We should have not include
> Spur and release Pharo 50 without it
> and keep new FFI and Spur for Pharo 60
> and keep GTTools for Pharo 60
>
> If this is your analysis then we are ok. Now you cannot tell me that
> pushing rubric was a mess.
> The state of the system (in particular the lack of good widgets) is a
> problem.
> Look at the keybindings why the keybinding is still the mess: simply
> because all the widgets and tools
> just nicely harcoded them.
> It does not mean that we should not fix them but you cannot
> fight day long against spur migration bugs
> fight day long against FFI glitches
> fix integration bugs of GT
> and get more steam for the rest
>
> Now let me tell you frankly I prefer to build useless mini new languages
> than fighting with ugly widgets
> so why did I supervised and worked with a guy to improve and push rubric?
> Because it was needed.
>
> Rubric is a big bad bunch of badly documented code
>
> indeed it is badly documented. Now it has examples.
> Now synectique and moose have been using in their product rubric.
>
> with lots of copy-paste garbage - we should do better.
> And since it was included I hear it was abandoned by alain
>
> No alain helped each time we asked him but he has severe family problems
> (the kind of problems that you do not
> want to have but you have to face).
>
> and TxText is the next.
>
> What can we say?
> I have no idea why igor disappeared and kind of divorced.
> Now the design of TxText is nice and we will have to invest. Bricks
> already used it and people looking
> at it mentioned that it is good.
> So the objectives is to drop rubric (because it is a hack and we know it
> but a hack which supports embellisment and icons)
> and use TxText.
>
> I see up to no development for TxText.
> The same for Athens, bugs or requests for conclusins I entered in FogBugz
> are, or will be closed (timout)
> because no one cares.
>
> But you see you are becoming the most aware for athens
> and what we should do is document document.
> Now I got ****EXHAUSTED**** to document things that I did not build or use
> daily. This effort for me is gigantic
> and I cannot do it each time.
>
> Instead Athens is used as it is or change by others just for its own
> projects (roassal, Bloc, Brick).
>
> Do you think that roassal is extended privately Athens. I would be
> surprised.
> I know that we all like what you did with the widgets because blocers can
> work in athens with default widgets
> and our goal is to throw all the morphic layer away and only use Athens.
>
> Now we should give feedback to blocers
>
>
>
>
>>
>> I personnally want to have new widgets, a real UI builder and massively
>> cleaning Spec.
>>
>
> me too, but what is the purpose of spec, if we replace all tools based on
> spec (debugger/inspector/...) with GT-Tools?
>
>
> We need a UI Builder and spec is a way to build widgets.
> Now before we get the perfect solution we need to make sure that we clean
> it.
> I would like to do that with Peter.
> But again there is no magic: some part of spec are ugly because of design
> but others are ugly
> because the widgets are poor.
>
> Now for me I have no problem cleaning Spec even if at the end we replace
> it by something else.
> We did that for the compiler, we are doing it for Morphic, ....
>
>
>
>
>> Now I would like to have multiple tool sets - I understand that people
>> like the new debugger (I do not like it) -
>> I want the possibility to have a mini tools tool set.
>>
>> If you want to clean Pharo
>>
>
> I fix bugs, there are many bugs.
>
>
> I know nicolai and I understand your frustration and I understand it:)
> I thank you everyday for that.
> I think that we should remove things from Pharo
> So the most important point for us is to get in place a process so that we
> can avoid to get monolithic again
> For example we need a process to have the possibility to remove project
> from the image and still build and modify an image with them.
> It will not change the problem that when a bug is there we have a bug but
> it should lower the stress.
>
> you can start cleaning Komitter stupid use of state pattern generating
>> a lot of garbage instead of having a single animated morph.
>>
>> We should clean Versionner- I have the impression that half of the
>> classes are not mandatory.
>>
>>
> Our tools are in a much more worse state than in Pharo 4, not clean, not
> stable.
>
> Where?
> Nautilus is much better to me.
> I used Versionner and it is working.
> CodeCritics
>
> I got some glitches with refactorings
>
> Do you have some issues?
>
> We are in code freeze since 6 weeks, and there are still many new changes
> instead of only bug fixes.
>
> I thought that it was not the case and I do not think so.
> So this is side effect of the cleaning of foundations.
> The problems is that we cannot block people working on the bootstrap
> forever.
>
>
> So nicolai what I would do is a roadmap for Pharo 60
> - there will be no Spur and FFI :)
> - so it will be consolidation
> - I would like to have release every six months (but it should be
> discussed)
> - for me I would like to have
> - cleaning Spec
> - cleaning another time nautilus
> - cleaning versionner
> - cleaning Komitter
> - Now we have epicea waiting
> - So Xtreams will be probably for later.
>
>
This is just too much indeed.
But we are learning a lot by doing this.
Phil
March 26, 2016
[pharo-project/pharo-core]
by GitHub
Branch: refs/tags/50662
Home: https://github.com/pharo-project/pharo-core
March 26, 2016
[pharo-project/pharo-core] 073848: 50662
by GitHub
Branch: refs/heads/5.0
Home: https://github.com/pharo-project/pharo-core
Commit: 07384816868e2ed549c735bfd4e6b4475499e6ab
https://github.com/pharo-project/pharo-core/commit/07384816868e2ed549c735bf…
Author: Jenkins Build Server <board(a)pharo-project.org>
Date: 2016-03-26 (Sat, 26 Mar 2016)
Changed paths:
M ConfigurationOfGTDebugger.package/ConfigurationOfGTDebugger.class/instance/symbolic versions/stable_.st
A ConfigurationOfGTDebugger.package/ConfigurationOfGTDebugger.class/instance/versions/version24_.st
M ConfigurationOfGTEventRecorder.package/ConfigurationOfGTEventRecorder.class/instance/symbolic versions/stable_.st
A ConfigurationOfGTEventRecorder.package/ConfigurationOfGTEventRecorder.class/instance/versions/version013_.st
M ConfigurationOfGTInspectorCore.package/ConfigurationOfGTInspectorCore.class/instance/symbolic versions/stable_.st
A ConfigurationOfGTInspectorCore.package/ConfigurationOfGTInspectorCore.class/instance/versions/version35_.st
M ConfigurationOfGTPlaygroundCore.package/ConfigurationOfGTPlaygroundCore.class/instance/symbolic versions/stable_.st
A ConfigurationOfGTPlaygroundCore.package/ConfigurationOfGTPlaygroundCore.class/instance/versions/version35_.st
M ConfigurationOfGTSpotter.package/ConfigurationOfGTSpotter.class/instance/symbolic versions/stable_.st
A ConfigurationOfGTSpotter.package/ConfigurationOfGTSpotter.class/instance/versions/version25_.st
M ConfigurationOfGToolkitCore.package/ConfigurationOfGToolkitCore.class/instance/symbolic versions/stable_.st
A ConfigurationOfGToolkitCore.package/ConfigurationOfGToolkitCore.class/instance/versions/version316_.st
M ConfigurationOfGlamourCore.package/ConfigurationOfGlamourCore.class/instance/symbolic versions/stable_.st
A ConfigurationOfGlamourCore.package/ConfigurationOfGlamourCore.class/instance/versions/version48_.st
M ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/symbolic versions/stable_.st
A ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version213_.st
M GT-Spotter.package/GTSpotter.class/instance/accessing/currentStep.st
A GT-Spotter.package/GTSpotter.class/instance/actions api/addStep_during_.st
A GT-Spotter.package/GTSpotter.class/instance/testing/hasSelected.st
A GT-Spotter.package/GTSpotter.class/instance/testing/hasSteps.st
M GT-Spotter.package/GTSpotter.class/instance/testing/isEmpty.st
A GT-Spotter.package/GTSpotterCandidateLink.class/instance/accessing/candidate.st
A GT-Spotter.package/GTSpotterCandidateLink.class/instance/accessing/next.st
A GT-Spotter.package/GTSpotterCandidateLink.class/instance/accessing/previous.st
R GT-Spotter.package/GTSpotterCandidateSelected.class/instance/accessing/candidateBrick.st
R GT-Spotter.package/GTSpotterCandidateSelected.class/instance/accessing/candidateBrick_.st
A GT-Spotter.package/GTSpotterCandidateSelected.class/instance/accessing/itemBrick.st
A GT-Spotter.package/GTSpotterCandidateSelected.class/instance/accessing/itemBrick_.st
R GT-Spotter.package/GTSpotterCandidateSelectedMoved.class/instance/accessing/candidateBrick.st
R GT-Spotter.package/GTSpotterCandidateSelectedMoved.class/instance/accessing/candidateBrick_.st
A GT-Spotter.package/GTSpotterCandidateSelectedMoved.class/instance/accessing/itemBrick.st
A GT-Spotter.package/GTSpotterCandidateSelectedMoved.class/instance/accessing/itemBrick_.st
M GT-Spotter.package/GTSpotterCandidatesList.class/instance/stream handling/onAmountChanged_in_.st
R GT-Spotter.package/GTSpotterCandidatesList.class/instance/testing/hasOnlyOneItem.st
M GT-Spotter.package/GTSpotterCategoryBrick.class/instance/event handling/onUnhovered.st
M GT-Spotter.package/GTSpotterCategoryTitleBrick.class/README.md
M GT-Spotter.package/GTSpotterCategoryTitleBrick.class/definition.st
A GT-Spotter.package/GTSpotterCategoryTitleBrick.class/instance/accessing/category.st
R GT-Spotter.package/GTSpotterCategoryTitleBrick.class/instance/accessing/categoryProcessor.st
R GT-Spotter.package/GTSpotterCategoryTitleBrick.class/instance/accessing/categoryProcessor_.st
A GT-Spotter.package/GTSpotterCategoryTitleBrick.class/instance/accessing/category_.st
M GT-Spotter.package/GTSpotterCategoryTitleBrick.class/instance/adding/addDiveInButton.st
M GT-Spotter.package/GTSpotterCategoryTitleBrick.class/instance/event-handling/onCandidateSelected.st
M GT-Spotter.package/GTSpotterCategoryTitleBrick.class/instance/event-handling/onUnhovered.st
M GT-Spotter.package/GTSpotterCategoryTitleBrick.class/instance/instance creation/on_category_.st
M GT-Spotter.package/GTSpotterHeaderBrick.class/instance/accessing/openSettingsBrowser.st
M GT-Spotter.package/GTSpotterItemActionbarBrick.class/instance/adding/addDiveInActionButton.st
A GT-Spotter.package/GTSpotterItemActionbarBrick.class/instance/testing/hasStepModel.st
M GT-Spotter.package/GTSpotterItemBrick.class/instance/accessing/stepModel_.st
M GT-Spotter.package/GTSpotterItemBrick.class/instance/actions/showActionbar.st
M GT-Spotter.package/GTSpotterItemBrick.class/instance/event handling/checkOrUncheck.st
M GT-Spotter.package/GTSpotterItemBrick.class/instance/notifying/notifySelected.st
M GT-Spotter.package/GTSpotterMorph.class/instance/accessing/privacyAgreementNotificationBrick_.st
M GT-Spotter.package/GTSpotterMorph.class/instance/actions/actDueTo_.st
M GT-Spotter.package/GTSpotterMorph.class/instance/actions/diveInCategoryDueTo_.st
M GT-Spotter.package/GTSpotterMorph.class/instance/actions/diveInDueTo_.st
M GT-Spotter.package/GTSpotterMorph.class/instance/actions/selectNextCandidateDueTo_.st
M GT-Spotter.package/GTSpotterMorph.class/instance/actions/selectNextCategory.st
M GT-Spotter.package/GTSpotterMorph.class/instance/actions/selectPreviousCandidateDueTo_.st
M GT-Spotter.package/GTSpotterMorph.class/instance/actions/selectPreviousCategory.st
M GT-Spotter.package/GTSpotterMorph.class/instance/instance creation/newPrivacyAgreementNotificationBrick.st
M GT-Spotter.package/GTSpotterMorph.class/instance/private/spotterModelDo_.st
M GT-Spotter.package/GTSpotterPaneBrick.class/instance/action/showPreview.st
M GT-Spotter.package/GTSpotterPreviewArrowBrick.class/instance/accessing/triangleBrick_.st
M GT-Spotter.package/GTSpotterPreviewArrowBrick.class/instance/event handling/onCandidateSelected_.st
M GT-Spotter.package/GTSpotterPreviewBrick.class/instance/event handling/onStepPopped.st
R GT-Spotter.package/GTSpotterPrivacyAgreementNotificationBrick.class/README.md
R GT-Spotter.package/GTSpotterPrivacyAgreementNotificationBrick.class/class/examples/exampleOpen.st
R GT-Spotter.package/GTSpotterPrivacyAgreementNotificationBrick.class/class/examples/gtExample.st
R GT-Spotter.package/GTSpotterPrivacyAgreementNotificationBrick.class/class/utils/openSettingsBrowser.st
R GT-Spotter.package/GTSpotterPrivacyAgreementNotificationBrick.class/definition.st
R GT-Spotter.package/GTSpotterPrivacyAgreementNotificationBrick.class/instance/accessing/messageBrick.st
R GT-Spotter.package/GTSpotterPrivacyAgreementNotificationBrick.class/instance/accessing/messageBrick_.st
R GT-Spotter.package/GTSpotterPrivacyAgreementNotificationBrick.class/instance/accessing/privacyMessage.st
R GT-Spotter.package/GTSpotterPrivacyAgreementNotificationBrick.class/instance/accessing/settingsButtonBrick.st
R GT-Spotter.package/GTSpotterPrivacyAgreementNotificationBrick.class/instance/accessing/settingsButtonBrick_.st
R GT-Spotter.package/GTSpotterPrivacyAgreementNotificationBrick.class/instance/accessing/settingsButtonLabel.st
R GT-Spotter.package/GTSpotterPrivacyAgreementNotificationBrick.class/instance/actions/openSettingsBrowser.st
R GT-Spotter.package/GTSpotterPrivacyAgreementNotificationBrick.class/instance/initialization/initialize.st
R GT-Spotter.package/GTSpotterPrivacyAgreementNotificationBrick.class/instance/instance creation/newButtonBrick.st
R GT-Spotter.package/GTSpotterPrivacyAgreementNotificationBrick.class/instance/instance creation/newTitleBrick.st
R GT-Spotter.package/GTSpotterPrivacyAgreementNotificationBrick.class/instance/preferences/sendUsageData.st
A GT-Spotter.package/GTSpotterProfiler.class/README.md
A GT-Spotter.package/GTSpotterProfiler.class/class/profiling/profileOneCycle.st
A GT-Spotter.package/GTSpotterProfiler.class/class/testing/isGlobalCategory.st
A GT-Spotter.package/GTSpotterProfiler.class/definition.st
A GT-Spotter.package/GTSpotterProfiler.class/instance/shortcuts/keymapProfileOneCycle.st
M GT-Spotter.package/GTSpotterResultsBrick.class/instance/accessing/categoryBrickFor_.st
A GT-Spotter.package/GTSpotterResultsBrick.class/instance/accessing/categoryBrickOf_.st
A GT-Spotter.package/GTSpotterResultsBrick.class/instance/accessing/categoryBrickOf_ifAbsent_.st
M GT-Spotter.package/GTSpotterResultsBrick.class/instance/accessing/stepModel_.st
M GT-Spotter.package/GTSpotterResultsBrick.class/instance/event handling/onCandidateSelected_.st
M GT-Spotter.package/GTSpotterResultsBrick.class/instance/event handling/onCandidatesAmountChanged_.st
M GT-Spotter.package/GTSpotterResultsBrick.class/instance/initialization/initialize.st
M GT-Spotter.package/GTSpotterStep.class/instance/accessing-dynamic/previousStep.st
M GT-Spotter.package/GTSpotterStep.class/instance/accessing/candidates.st
M GT-Spotter.package/GTSpotterStep.class/instance/accessing/selected.st
R GT-Spotter.package/GTSpotterStep.class/instance/accessing/selectedCandidate.st
M GT-Spotter.package/GTSpotterStep.class/instance/accessing/selectedCategory.st
M GT-Spotter.package/GTSpotterStep.class/instance/actions/actDueTo_.st
M GT-Spotter.package/GTSpotterStep.class/instance/actions/canDiveInSelectedCandidate.st
M GT-Spotter.package/GTSpotterStep.class/instance/actions/canDiveIn_.st
M GT-Spotter.package/GTSpotterStep.class/instance/actions/diveInDueTo_.st
A GT-Spotter.package/GTSpotterStep.class/instance/event processing/onCandidateAdded.st
A GT-Spotter.package/GTSpotterStep.class/instance/selecting/deselect.st
M GT-Spotter.package/GTSpotterStep.class/instance/selecting/selectFirst.st
M GT-Spotter.package/GTSpotterStep.class/instance/selecting/selectNextCategory.st
M GT-Spotter.package/GTSpotterStep.class/instance/selecting/selectNextDueTo_.st
M GT-Spotter.package/GTSpotterStep.class/instance/selecting/selectPreviousDueTo_.st
M GT-Spotter.package/GTSpotterStep.class/instance/selecting/selected_dueTo_.st
A GT-Spotter.package/GTSpotterStep.class/instance/testing/hasCandidates.st
M GT-Spotter.package/GTSpotterStep.class/instance/testing/hasPreviousNavigationFromClass_.st
M GT-Spotter.package/GTSpotterStep.class/instance/testing/hasPreviousStep.st
A GT-Spotter.package/GTSpotterStep.class/instance/testing/hasSelected.st
A GT-Spotter.package/GTSpotterStep.class/instance/testing/isCategorySelected_.st
R GT-Spotter.package/GTSpotterStep.class/instance/testing/isEmpty.st
A GT-Spotter.package/GTSpotterStep.class/instance/testing/isSelected_.st
A GT-Spotter.package/GTSpotterStep.class/instance/zz-deprecated/isEmpty.st
M GT-Spotter.package/GTSpotterStepsBreadcrumb.class/instance/events-processing/onStepAdded_.st
M GT-Spotter.package/GTSpotterWidgetThemer.class/instance/values/previewArrowGapHack.st
A GT-SpotterExtensions-Core.package/GTSelector.class/README.md
A GT-SpotterExtensions-Core.package/GTSelector.class/class/examples/gtExampleNew.st
A GT-SpotterExtensions-Core.package/GTSelector.class/class/private/substring_filter_.st
A GT-SpotterExtensions-Core.package/GTSelector.class/definition.st
A GT-SpotterExtensions-Core.package/GTSelector.class/instance/accessing/name.st
A GT-SpotterExtensions-Core.package/GTSelector.class/instance/accessing/name_.st
A GT-SpotterExtensions-Core.package/GTSelector.class/instance/initialization/initialize.st
A GT-SpotterExtensions-Core.package/GTSelector.class/instance/printing/gtDisplayOn_.st
A GT-SpotterExtensions-Core.package/GTSelector.class/instance/private accessing/addMethod_.st
A GT-SpotterExtensions-Core.package/GTSelector.class/instance/querying/implementors.st
A GT-SpotterExtensions-Core.package/GTSelector.class/instance/querying/senders.st
A GT-SpotterExtensions-Core.package/GTSelector.class/instance/ui/spotterImplementorsFor_.st
A GT-SpotterExtensions-Core.package/GTSelector.class/instance/ui/spotterPreviewIn_.st
A GT-SpotterExtensions-Core.package/GTSelector.class/instance/ui/spotterSendersFor_.st
R GT-SpotterExtensions-Core.package/GTSelectorImplementors.class/README.md
R GT-SpotterExtensions-Core.package/GTSelectorImplementors.class/class/examples/gtExampleNew.st
R GT-SpotterExtensions-Core.package/GTSelectorImplementors.class/class/private/substring_filter_.st
R GT-SpotterExtensions-Core.package/GTSelectorImplementors.class/definition.st
R GT-SpotterExtensions-Core.package/GTSelectorImplementors.class/instance/accessing/addMethod_.st
R GT-SpotterExtensions-Core.package/GTSelectorImplementors.class/instance/accessing/name.st
R GT-SpotterExtensions-Core.package/GTSelectorImplementors.class/instance/accessing/name_.st
R GT-SpotterExtensions-Core.package/GTSelectorImplementors.class/instance/initialization/initialize.st
R GT-SpotterExtensions-Core.package/GTSelectorImplementors.class/instance/printing/gtDisplayOn_.st
R GT-SpotterExtensions-Core.package/GTSelectorImplementors.class/instance/querying/implementors.st
R GT-SpotterExtensions-Core.package/GTSelectorImplementors.class/instance/querying/senders.st
R GT-SpotterExtensions-Core.package/GTSelectorImplementors.class/instance/ui/spotterImplementorsFor_.st
R GT-SpotterExtensions-Core.package/GTSelectorImplementors.class/instance/ui/spotterPreviewIn_.st
R GT-SpotterExtensions-Core.package/GTSelectorImplementors.class/instance/ui/spotterSendersFor_.st
A GT-SpotterExtensions-Core.package/extension/CompiledMethod/instance/spotterForMessagesFor_.st
M GT-SpotterExtensions-Core.package/extension/CompiledMethod/instance/spotterForSendersFor_.st
M GT-SpotterExtensions-Core.package/extension/GTSpotter/instance/spotterClipboardFor_.st
M GT-SpotterExtensions-Core.package/extension/GTSpotter/instance/spotterForMessagesFor_.st
M GT-SpotterExtensions-Core.package/extension/MCWorkingCopy/instance/spotterAllRepositoriesFor_.st
M GT-SpotterExtensions-Core.package/extension/MCWorkingCopy/instance/spotterPackageRepositoriesFor_.st
M GT-SpotterExtensions-Core.package/extension/MenuMorph/instance/spotterItemsFor_.st
M GT-Tests-Spotter.package/GTSpotterStepTest.class/instance/private/assertDiveIn_.st
A Glamour-Morphic-Brick.package/GLMPhlowPharoMethodBrick.class/instance/accessing/getText.st
A Glamour-Morphic-Brick.package/GLMPhlowPharoMethodBrick.class/instance/accessing/interactionModel.st
M Glamour-Morphic-Brick.package/GLMPhlowPharoMethodBrick.class/instance/phlow/installEntity.st
A Glamour-Morphic-Brick.package/GLMPrivacyAgreementBrick.class/README.md
A Glamour-Morphic-Brick.package/GLMPrivacyAgreementBrick.class/class/examples/exampleOpen.st
A Glamour-Morphic-Brick.package/GLMPrivacyAgreementBrick.class/class/examples/gtExample.st
A Glamour-Morphic-Brick.package/GLMPrivacyAgreementBrick.class/class/utils/openSettingsBrowser.st
A Glamour-Morphic-Brick.package/GLMPrivacyAgreementBrick.class/definition.st
A Glamour-Morphic-Brick.package/GLMPrivacyAgreementBrick.class/instance/accessing/messageBrick.st
A Glamour-Morphic-Brick.package/GLMPrivacyAgreementBrick.class/instance/accessing/messageBrick_.st
A Glamour-Morphic-Brick.package/GLMPrivacyAgreementBrick.class/instance/accessing/privacyMessage.st
A Glamour-Morphic-Brick.package/GLMPrivacyAgreementBrick.class/instance/accessing/settingsButtonBrick.st
A Glamour-Morphic-Brick.package/GLMPrivacyAgreementBrick.class/instance/accessing/settingsButtonBrick_.st
A Glamour-Morphic-Brick.package/GLMPrivacyAgreementBrick.class/instance/accessing/settingsButtonLabel.st
A Glamour-Morphic-Brick.package/GLMPrivacyAgreementBrick.class/instance/actions/openSettingsBrowser.st
A Glamour-Morphic-Brick.package/GLMPrivacyAgreementBrick.class/instance/initialization/initialize.st
A Glamour-Morphic-Brick.package/GLMPrivacyAgreementBrick.class/instance/instance creation/newButtonBrick.st
A Glamour-Morphic-Brick.package/GLMPrivacyAgreementBrick.class/instance/instance creation/newTitleBrick.st
A Glamour-Morphic-Brick.package/GLMPrivacyAgreementBrick.class/instance/preferences/sendUsageData.st
M Rubric.package/RubSmalltalkEditor.class/instance/new selection/computeSelectionIntervalForCurrentLine.st
R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50661.st
A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50662.st
R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50661.st
A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50662.st
M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
Log Message:
-----------
50662
Moose
http://files.pharo.org/image/50/50662.zip
March 26, 2016
Re: [Pharo-dev] Fwd: Squeak 5 on Raspberry Pi
by phil＠highoctane.be
In Tiki, our versioning policy is like this:
https://tiki.org/Versions
Going on nicely since 2009.
Phil
This email has been sent from a virus-free computer protected by Avast.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…>
<#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
On Fri, Mar 25, 2016 at 11:32 PM, Eliot Miranda <eliot.miranda(a)gmail.com>
wrote:
> Hi Stef,
>
> On Fri, Mar 25, 2016 at 2:27 PM, stepharo <stepharo(a)free.fr> wrote:
>
>> So guys, you do not want Xtreams (and prefer to use Streams that have
>> been "designed" decades ago) ;D ?
>> no bootstrapped core (clement you do not want to have a mini image :) ?
>> and a new UI frameworks?
>>
>
> yes, of course :-)
>
>
>> I personnally want to have new widgets, a real UI builder and massively
>> cleaning Spec.
>> Now I would like to have multiple tool sets - I understand that people
>> like the new debugger (I do not like it) -
>> I want the possibility to have a mini tools tool set.
>>
>
> +1
>
>
>> If you want to clean Pharo you can start cleaning Komitter stupid use of
>> state pattern generating
>> a lot of garbage instead of having a single animated morph.
>>
>> We should clean Versionner- I have the impression that half of the
>> classes are not mandatory.
>>
>
> I don't think this is either or. I don't think Hilaire is saying "don't
> do feature-rich releases". I think Hilaire is saying "do separate
> feature-rich and consolidation releases".
>
> I think Hilaire is making a good suggestion of having some releases being
> for new functionality and some for consolidation. So perhaps the community
> could schedule a Pharo N, followed by a Pharo N.1, or schedule a Pharo M,
> where M is even (or odd) and a Pharo N, where N is odd (or even), and have
> the N.1, or N is odd (or even) releases being consolidation releases as
> Hilaire describes, with no new features and only bug fixes and performance
> improvements. If the community can manage it, it could do one new feature,
> followed by one consolidation release a year. But if so, the community
> needs to be serious about the consolidation releases and put real effort
> into them.
>
> The advantage for the broader user base is clear; there is a steady stream
> of releases that more conservative users can use, that exhibits good
> stability and better performance than the bleeding edge.
>
> Also, there's no reason why these release cycles can't overlap. The only
> time they must not overlap is when the community needs to focus on the new
> release. So for example, for two months of the year, six months apart, the
> community should focus on the new release, be it consolidation or
> feature-rich, and make sure we release promptly and correctly. But the
> other ten months of the year there's no reason why the community cannot
> work on either release. This requires infrastructure such as two
> repositories, one for each, such as pharo-features and pharo-stable, and
> the discipline to separate one's work correctly, but it could be a really
> good thing. I'm sure others can think this through better than I. What do
> others suggest?
>
> Stef
>>
>> 2016-03-25 18:18 GMT+01:00 Hilaire <hilaire(a)drgeo.eu>:
>>
>>> Not exactly related to Announcement, but I remember when I first port
>>> DrGeo to Squeak (at that time Pharo did not exist) I used a lot of
>>> change/update when objects in the canvas changed. It was terribly slow,
>>> and later opted for a top-down update in the list of object.
>>>
>>> So some sometime what look like a cool stuff (decoupled objects) is just
>>> a drag.
>>>
>>> Regarding optimizing, I share my opinion here months ago, I think Pharo
>>> need consolidation releases: no new features, only bugs fix and speed
>>> improvement. There are enough new features in Pharo for a couple of
>>> years, but the product need to *be* solid and *feel* solid.
>>>
>>
>> +1
>>
>>
>>>
>>> Hilaire
>>>
>>> Le 25/03/2016 12:33, Stephan Eggermont a écrit :
>>> > On 25-03-16 11:49, Nicolai Hess wrote:
>>> >> Morphic drasticallly slower ? I would expect morphic code is mostly
>>> >> the same in pharo and squeak. If pharo is slower, this is a good
>>> >> starting point for optimising. Can you gives some hints?
>>> > I do not have the impression that morphic is so much slower.
>>> > We had/have a problem of too many announcements being send and
>>> > too many redraws happening.
>>> >
>>> > Stephan
>>> >
>>> >
>>>
>>> --
>>> Dr. Geo
>>> http://drgeo.eu
>>>
>>>
>>>
>>
>>
>
>
> --
> _,,,^..^,,,_
> best, Eliot
>
March 26, 2016
Re: [Pharo-dev] Fwd: Squeak 5 on Raspberry Pi
by phil＠highoctane.be
Yes, I want all of the good stuff.
Let's always remember that when the platoon soldiers stop complaining, it
is time to watch your back for a knife.
Looks like we are a long way from there.
Phil
This email has been sent from a virus-free computer protected by Avast.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…>
<#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
On Fri, Mar 25, 2016 at 10:27 PM, stepharo <stepharo(a)free.fr> wrote:
> So guys, you do not want Xtreams (and prefer to use Streams that have been
> "designed" decades ago) ;D ?
> no bootstrapped core (clement you do not want to have a mini image :) ?
> and a new UI frameworks?
>
> I personnally want to have new widgets, a real UI builder and massively
> cleaning Spec.
> Now I would like to have multiple tool sets - I understand that people
> like the new debugger (I do not like it) -
> I want the possibility to have a mini tools tool set.
>
> If you want to clean Pharo you can start cleaning Komitter stupid use of
> state pattern generating
> a lot of garbage instead of having a single animated morph.
>
> We should clean Versionner- I have the impression that half of the classes
> are not mandatory.
>
> Stef
>
>
>
> 2016-03-25 18:18 GMT+01:00 Hilaire <hilaire(a)drgeo.eu>:
>
>> Not exactly related to Announcement, but I remember when I first port
>> DrGeo to Squeak (at that time Pharo did not exist) I used a lot of
>> change/update when objects in the canvas changed. It was terribly slow,
>> and later opted for a top-down update in the list of object.
>>
>> So some sometime what look like a cool stuff (decoupled objects) is just
>> a drag.
>>
>> Regarding optimizing, I share my opinion here months ago, I think Pharo
>> need consolidation releases: no new features, only bugs fix and speed
>> improvement. There are enough new features in Pharo for a couple of
>> years, but the product need to *be* solid and *feel* solid.
>>
>
> +1
>
>
>>
>> Hilaire
>>
>> Le 25/03/2016 12:33, Stephan Eggermont a écrit :
>> > On 25-03-16 11:49, Nicolai Hess wrote:
>> >> Morphic drasticallly slower ? I would expect morphic code is mostly
>> >> the same in pharo and squeak. If pharo is slower, this is a good
>> >> starting point for optimising. Can you gives some hints?
>> > I do not have the impression that morphic is so much slower.
>> > We had/have a problem of too many announcements being send and
>> > too many redraws happening.
>> >
>> > Stephan
>> >
>> >
>>
>> --
>> Dr. Geo
>> http://drgeo.eu
>>
>>
>>
>
>
March 26, 2016
[pharo-project/pharo-core]
by GitHub
Branch: refs/tags/50661
Home: https://github.com/pharo-project/pharo-core
March 26, 2016
[pharo-project/pharo-core] e6b9ee: 50661
by GitHub
Branch: refs/heads/5.0
Home: https://github.com/pharo-project/pharo-core
Commit: e6b9ee071d8bd1eccac563b8ab0fce718f728d3c
https://github.com/pharo-project/pharo-core/commit/e6b9ee071d8bd1eccac563b8…
Author: Jenkins Build Server <board(a)pharo-project.org>
Date: 2016-03-26 (Sat, 26 Mar 2016)
Changed paths:
R Keymapping-Tests.package/KMDispatcherTestCase.class/class/as yet unclassified/keymapEventBuilderClass.st
R Keymapping-Tests.package/KMKeymapTest.class/class/as yet unclassified/keymapEventBuilderClass.st
R Keymapping-Tests.package/KeymapBuilderTest.class/class/as yet unclassified/keymapEventBuilderClass.st
M Nautilus.package/NautilusUI.class/instance/source code area/compileAMethodFromCategory_withSource_notifying_.st
R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50660.st
A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50661.st
R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50660.st
A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50661.st
M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
M Tool-Base.package/AbstractTool.class/instance/class/addClassIn_.st
M Tool-Base.package/AbstractTool.class/instance/class/addTraitIn_.st
R Tool-Transcript.package/extension/ThreadSafeTranscript/class/examples.st
R Tool-Transcript.package/extension/ThreadSafeTranscript/class/examplesConcurrent.st
R Tool-Transcript.package/extension/ThreadSafeTranscript/class/examplesForegroundUpdate.st
Log Message:
-----------
50661
17891 creating of a new method in "no messages" category does not update methods list in Nautilus
https://pharo.fogbugz.com/f/cases/17891
16309 ThreadSafeTranscript>>examples doesnt work anymore
https://pharo.fogbugz.com/f/cases/16309
16922 Nautilus: Using class pane menu entry "Add class" can cause problems
https://pharo.fogbugz.com/f/cases/16922
17878 KM calls to unimplemented methods
https://pharo.fogbugz.com/f/cases/17878
http://files.pharo.org/image/50/50661.zip
March 26, 2016
Re: [Pharo-dev] Fwd: Squeak 5 on Raspberry Pi
by stepharo
> I want a clean and stable core.
me too.
Now you will not my core. Because there is no UI no announcement...
> The way Rubric and GT-Tools were pushed into the core was a mess.
No I cannot let you to say that. I'm sorry. We spent 4 months cleaning
Nautilus
and Rubric is not optimal but we decided that forcing to adapt to Rubric
was a good move
for the next one. We did it to help
- breakpoints
- QA feedback
Rubric was pushed in Pharo over the summer. So if we cannot change
something as important that
that more than 8 months before the release then we should better stop to
do pharo.
Because for Rubric ***I*** planned it in advance with a stabilisation
phase.
Now Pharo 50 got far too many new features
We should have not include
Spur and release Pharo 50 without it
and keep new FFI and Spur for Pharo 60
and keep GTTools for Pharo 60
If this is your analysis then we are ok. Now you cannot tell me that
pushing rubric was a mess.
The state of the system (in particular the lack of good widgets) is a
problem.
Look at the keybindings why the keybinding is still the mess: simply
because all the widgets and tools
just nicely harcoded them.
It does not mean that we should not fix them but you cannot
fight day long against spur migration bugs
fight day long against FFI glitches
fix integration bugs of GT
and get more steam for the rest
Now let me tell you frankly I prefer to build useless mini new languages
than fighting with ugly widgets
so why did I supervised and worked with a guy to improve and push rubric?
Because it was needed.
> Rubric is a big bad bunch of badly documented code
indeed it is badly documented. Now it has examples.
Now synectique and moose have been using in their product rubric.
> with lots of copy-paste garbage - we should do better.
> And since it was included I hear it was abandoned by alain
No alain helped each time we asked him but he has severe family problems
(the kind of problems that you do not
want to have but you have to face).
> and TxText is the next.
What can we say?
I have no idea why igor disappeared and kind of divorced.
Now the design of TxText is nice and we will have to invest. Bricks
already used it and people looking
at it mentioned that it is good.
So the objectives is to drop rubric (because it is a hack and we know it
but a hack which supports embellisment and icons)
and use TxText.
> I see up to no development for TxText.
> The same for Athens, bugs or requests for conclusins I entered in
> FogBugz are, or will be closed (timout)
> because no one cares.
But you see you are becoming the most aware for athens
and what we should do is document document.
Now I got ****EXHAUSTED**** to document things that I did not build or
use daily. This effort for me is gigantic
and I cannot do it each time.
> Instead Athens is used as it is or change by others just for its own
> projects (roassal, Bloc, Brick).
Do you think that roassal is extended privately Athens. I would be
surprised.
I know that we all like what you did with the widgets because blocers
can work in athens with default widgets
and our goal is to throw all the morphic layer away and only use Athens.
Now we should give feedback to blocers
>
>
> I personnally want to have new widgets, a real UI builder and
> massively cleaning Spec.
>
>
> me too, but what is the purpose of spec, if we replace all tools based
> on spec (debugger/inspector/...) with GT-Tools?
We need a UI Builder and spec is a way to build widgets.
Now before we get the perfect solution we need to make sure that we
clean it.
I would like to do that with Peter.
But again there is no magic: some part of spec are ugly because of
design but others are ugly
because the widgets are poor.
Now for me I have no problem cleaning Spec even if at the end we replace
it by something else.
We did that for the compiler, we are doing it for Morphic, ....
> Now I would like to have multiple tool sets - I understand that
> people like the new debugger (I do not like it) -
> I want the possibility to have a mini tools tool set.
>
> If you want to clean Pharo
>
>
> I fix bugs, there are many bugs.
I know nicolai and I understand your frustration and I understand it:)
I thank you everyday for that.
I think that we should remove things from Pharo
So the most important point for us is to get in place a process so that
we can avoid to get monolithic again
For example we need a process to have the possibility to remove project
from the image and still build and modify an image with them.
It will not change the problem that when a bug is there we have a bug
but it should lower the stress.
> you can start cleaning Komitter stupid use of state pattern
> generating
> a lot of garbage instead of having a single animated morph.
>
> We should clean Versionner- I have the impression that half of the
> classes are not mandatory.
>
>
> Our tools are in a much more worse state than in Pharo 4, not clean,
> not stable.
Where?
Nautilus is much better to me.
I used Versionner and it is working.
CodeCritics
I got some glitches with refactorings
Do you have some issues?
> We are in code freeze since 6 weeks, and there are still many new
> changes instead of only bug fixes.
I thought that it was not the case and I do not think so.
So this is side effect of the cleaning of foundations.
The problems is that we cannot block people working on the bootstrap
forever.
So nicolai what I would do is a roadmap for Pharo 60
- there will be no Spur and FFI :)
- so it will be consolidation
- I would like to have release every six months (but it should be
discussed)
- for me I would like to have
- cleaning Spec
- cleaning another time nautilus
- cleaning versionner
- cleaning Komitter
- Now we have epicea waiting
- So Xtreams will be probably for later.
March 26, 2016
Re: [Pharo-dev] Fwd: Squeak 5 on Raspberry Pi
by Sven Van Caekenberghe
I totally do not agree with many of the arguments in this thread.
But I do not want to discuss them under this label.
Please start a new thread, if you want to.
> On 26 Mar 2016, at 05:40, Hernán Morales Durand <hernan.morales(a)gmail.com> wrote:
>
>
>
> 2016-03-25 19:32 GMT-03:00 Eliot Miranda <eliot.miranda(a)gmail.com>:
> Hi Stef,
>
> On Fri, Mar 25, 2016 at 2:27 PM, stepharo <stepharo(a)free.fr> wrote:
> So guys, you do not want Xtreams (and prefer to use Streams that have been "designed" decades ago) ;D ?
> no bootstrapped core (clement you do not want to have a mini image :) ? and a new UI frameworks?
>
> yes, of course :-)
>
> I personnally want to have new widgets, a real UI builder and massively cleaning Spec.
> Now I would like to have multiple tool sets - I understand that people like the new debugger (I do not like it) -
> I want the possibility to have a mini tools tool set.
>
> +1
>
> If you want to clean Pharo you can start cleaning Komitter stupid use of state pattern generating
> a lot of garbage instead of having a single animated morph.
>
> We should clean Versionner- I have the impression that half of the classes are not mandatory.
>
> I don't think this is either or. I don't think Hilaire is saying "don't do feature-rich releases". I think Hilaire is saying "do separate feature-rich and consolidation releases".
>
> I think Hilaire is making a good suggestion of having some releases being for new functionality and some for consolidation. So perhaps the community could schedule a Pharo N, followed by a Pharo N.1, or schedule a Pharo M, where M is even (or odd) and a Pharo N, where N is odd (or even), and have the N.1, or N is odd (or even) releases being consolidation releases as Hilaire describes, with no new features and only bug fixes and performance improvements. If the community can manage it, it could do one new feature, followed by one consolidation release a year. But if so, the community needs to be serious about the consolidation releases and put real effort into them.
>
> The advantage for the broader user base is clear; there is a steady stream of releases that more conservative users can use, that exhibits good stability and better performance than the bleeding edge.
>
> Also, there's no reason why these release cycles can't overlap. The only time they must not overlap is when the community needs to focus on the new release. So for example, for two months of the year, six months apart, the community should focus on the new release, be it consolidation or feature-rich, and make sure we release promptly and correctly. But the other ten months of the year there's no reason why the community cannot work on either release. This requires infrastructure such as two repositories, one for each, such as pharo-features and pharo-stable, and the discipline to separate one's work correctly, but it could be a really good thing. I'm sure others can think this through better than I. What do others suggest?
>
> In my opinion, that sounds like a very good and more serious approach for the whole community. The only problem I see is an explosion of Pharo flavors like happened in Squeak years ago, because many people want promotion of their own image (which is ok but also reflects lack of consensus), but is better than having new core projects with developers abandoning before time or obscure decisions imposing a new debugger without ANY poll.
>
> Now I don't want to waste time on definitions of "solid", but I can tell you Pharo now feels slow.
>
> About having to ask "spend some time optimising tools" just a few weeks before a release... Sorry guys I know you work a lot on making good quality stuff, but seems like the current way of integrating tools **is NOT working**.
>
> Where is the policy for integrating packages and tools into the core?
> Where are the priorities? Why they are priorities? How many votes gets each?
>
> Want more contributors?
> Start with clean visible rules and listen to users.
>
> We all want UFFI, Xtreams, mini-image, new UI frameworks & builder, etc. but not at any cost.
>
> Hernán
March 26, 2016