- Pharo-users - lists.pharo.org

Re: [Pharo-users] Gettext with pharo 3 and seaside 3.1.2

by stepharo

Hi johan usman and other I would like to get a clearer picture. https://pharo.fogbugz.com/f/cases/13655/System-Localization-and-Gettext-hav… We could change the name of in the PharoExtras package gettext so that we do not have conflicts with the in-image mechanisms. I'm skeptical about all these translated messages everywhere. What people do for the applications? Then what is the seaside-Getext? Is is a superset of pharoExtras-gettext? For application not doing web, does it make sense to use it? Is it packaged separately? Stef

Sept. 13, 2014

Re: [Pharo-users] Gettext with pharo 3 and seaside 3.1.2

by Johan Brichau

Hi, The Seaside-Gettext package is in the Seaside repository http://www.smalltalkhub.com/#!/~Seaside/Seaside30Addons The package in the PharoExtras repository is a relic. The ConfigurationOfSeaside3 correctly references the Seaside-Gettext package and itâs absolutely functional (using this in production systems). What is a bit silly is that the ConfigurationOfSeaside3 relies on people chosing the appropriate groups to load and the Pharo configuration browser always loads the default transparantly. I will probably update that for Seaside 3.2.0, so that the default loads everything for newcomers, but for the current version some load configurations might rely on it and thatâs the way it is. Johan On 08 Sep 2014, at 11:16, Hilaire <hilaire(a)drgeo.eu> wrote: > What is the purpose of the seaside-gettext package ? > Is it a relic or is it useful? Gettext is orthogonal to Seaside. > > Hilaire > > Le 07/09/2014 15:32, Peter Schorsch a Ã©crit : >> But then I had to realize that the seaside-gettext package was not >> installed; and also no gettext package. I found a gettext package in >> the repositoryhttp://smalltalkhub.com/mc/PharoExtras/Gettext. >> >> I installed the package ConfigurationOfGettext, but the >> configuraitonof-browser does not show it. So I installed the package >> Gettext via monticello. > > > -- > Dr. Geo - http://drgeo.eu > iStoa - http://istao.drgeo.eu > >

Sept. 13, 2014

Re: [Pharo-users] Moose browsers: Updating an object value **explicitly** from a text pane

by Offray Vladimir Luna CÃ¡rdenas

Hi, I have tried a new strategy. I hope this time get some questions or some pointers about what to do when a thread gets frozen, like this one. For details on how to load the project on a vanilla Moose beta 5.0 image follow the instructions at: http://wiki.hackbo.co/doku.php/herramientas:grafoscopio:en:install and then run "UbakyeBrowser open". I have divided the code and now the browser it is composed with tree main parts: The first one builds the browser: =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- UbakyeBrowser>>buildBrowser "... Snipped code ..." (browser transmit) to: #tree; andShow: [:a | self treeOn: a]. (browser transmit) to: #body; from: #tree; andShow: [ :a | self bodyOn: a]. "... Snipped code ..." =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- The second one builds the tree. The specific part which sends a constant message for changing the body contents is this: =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- UbakyeBrowser>> TreeOn: constructor "... Snipped code ..." act: [:treePresentation | (treePresentation selection isNotNil) ifTrue: [treePresentation selection body: 'Cambiado!']. treePresentation update] icon: GLMUIThemeExtraIcons glamorousRefresh entitled: 'Update body'; "... Snipped code ..." =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- And the third one just shows the body from the tree node like this: =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- UbakyeBrowser>> bodyOn: constructor "Shows the body of a selected node" (constructor text) title: 'Cuerpo | Body '; format:[:eachNode | (eachNode body) isNil ifTrue: [ '' ] ifFalse: [ eachNode body]]. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- So as you can see, the message I'm sending to update the node body, explicitly by pressing a button, is a constant one (treePresentation selection body: 'Cambiado!'), while I would like to send anything that is contained in the text pane of the current node. I still don't get how to do it with transmissions and I imagine that is related with something like toOutsidePort or some message like that, but I still don't get it. Any help will be appreciated or is anything I can do to move this forward, let me know. Cheers, Offray On 09/07/2014 09:56 PM, Offray Vladimir Luna CÃ¡rdenas wrote: > Hi again, > > I have opted for another option: Manually updating objects from text > panes. I have a method for showing the content of a node body: > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > bodyOn: constructor > "Shows the body of a selected node" > (constructor text) > title: 'Cuerpo | Body '; > format:[:eachNode | > (eachNode body) isNil > ifTrue: [ '' ] > ifFalse: [ eachNode body]]; > act: [:text | text inspect ] > icon: GLMUIThemeExtraIcons glamorousRefresh > entitled: 'Save body'. > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > At this moment I have only "text inspect" as an action for the text > pane, but when I inspect it, I can see in the "Pane Ports" tab that any > text wrote there gets updated up to the moment of clicking in the > button. What I would like is to send the updated text as an argument for > the "body:" setter of the UbakyeNode object. I have seen in the PBE2 > chapter about Glamorous that I can used ports to send values to the > outside, but still I don't get how. > > Remember that you can upload the code by following the instructions here: > > http://wiki.hackbo.co/doku.php/herramientas:grafoscopio:en:install > > Any advice on this is appreciated. > > Thanks in advance, > > Offray > > On 09/05/2014 10:58 PM, Offray Vladimir Luna CÃ¡rdenas wrote: >> Hi Doru an community, >> >> In almost a week from now I will write an small revision article about >> this prototyping exercise on Moose/Glamour/Pharo, for structured >> writing. My ideal would be to write it inside this prototype, but for >> that I need to be able to edit and store the changes on the tree and its >> node contents. Hopefully it won't take too much, even for a newbie like >> me. Even if is not possible, and I need to go back to Leo Editor >> (http://leoeditor.com/) for reporting and writing the article, this >> exercise has been really valuable. >> >> This are my issues so far: >> >> Auto-updating objects from the browser is working but I'm having >> problems to integrate this with my code. To follow better what is >> happening just: >> >> 1. Follow the installation notes on: >> http://wiki.hackbo.co/doku.php/herramientas:grafoscopio:en:install >> >> 2. Run this code: >> >> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >> | text mainTree | >> mainTree := UbakyeNode new. >> mainTree becomeDefaultTree. >> text := (mainTree children at: 1) body. >> GLMCompositePresentation new wrapper >> with: [ :wrapper | >> wrapper show: [ :a | >> a text ]. >> wrapper transmit >> fromOutsidePort: #text; >> toOutsidePort: #portIDoNotCareAbout; >> transformed: [ :textComingFromThePresentation | >> text := textComingFromThePresentation ] ]; >> openOn: text. >> (mainTree children at: 1) body: text >> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >> >> If I comment the last line, I can explore the Browser Tree and see how >> #text updates automatically, but if I leave it uncommented I can explore >> the mainTree and see that is not updating. >> >> Also I tried to put the transmit parameters in the build browser >> transmit parameter, just here: >> >> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >> UbakyeBrowser>>buildBrowser >> >> "(... snipped code)" >> (browser transmit) >> to: #body; >> from: #tree; >> andShow: [ :a | self bodyOn: a]. >> "(...snipped code)" >> >> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >> >> replacing "to:", "from:" and "andShow:" for "fromOutsidePort:", >> "toOutsidePort:" and "transformed:" as shown in your example, but then >> the current selection in the tree got disconnected from the body pane. >> >> I would mind to have a explicit button or keyboard shortcut to take what >> is currently on a text pane and send it all to a particular node for >> updating, if this is the quickest workaround. So, How can I made this? >> >> Also, Doru showed to me a way to invoke inspector on the current >> selected node. Suppose that I want to have an emergent window to edit >> the node header and some tags on it. Is this possible? >> >> >> Cheers and thanks in advance, >> >> Offray >> >> On 09/03/2014 04:27 AM, Tudor Girba wrote: >>> Hi, >>> >>> As I said before, right now, Glamour does not easily the behavior you >>> want, but >>> you can abuse an existing mechanism of capturing changes of a port >>> through a >>> transmission that transforms that value. >>> >>> Here is an example: >>> >>> text := ''. >>> GLMCompositePresentation new wrapper >>> with: [ :wrapper | >>> wrapper show: [ :a | >>> a text ]. >>> wrapper transmit fromOutsidePort: #text; toOutsidePort: >>> #portIDoNotCareAbout; >>> transformed: [ :textComingFromThePresentation | text := >>> textComingFromThePresentation ] ]; >>> openOn: text >>> >>> In this example, we create a transmission that originates in the #text >>> port that >>> will be populated every time you modify something. This transmission >>> sends the >>> value to #portIDoNotCareAbout only to have access to the >>> transformation block >>> where you can do what you want with the textComingFromThePresentation. >>> >>> To check the behavior: >>> - execute the code in a Playground, >>> - type something in the text area that opens, >>> - inspect the text variable >>> ==> you will see that it contains the latest contents from the text >>> editor >>> >>> We should promote this mechanism explicitly in Glamour, but in the >>> meantime it >>> is probably sufficient for your case. >>> >>> Doru >>> >>> >>> On Wed, Sep 3, 2014 at 4:47 AM, Offray Vladimir Luna CÃ¡rdenas >>> <offray(a)riseup.net >>> <mailto:offray@riseup.net>> wrote: >>> >>> Hi, >>> >>> I'm trying to restate my question to see if I have more luck with >>> any answer >>> this time. >>> >>> I'm making advances with an outliner like app for writing and now >>> I can add >>> nodes move them and store them in the really nice STON format. >>> But because >>> information on trees is not editable, I would like to try another >>> approach: >>> To create an emergent window and put the node tree and node tags >>> on it, and >>> the update the this values on the tree node. >>> Also, I would like to update some objects from the a Glamour text >>> pane, >>> without any special button or action, just while I'm writing on >>> them. If >>> this is not possible which is the message to select all text in a >>> body panel >>> and to send it to a object? >>> >>> I will be doing some further advances by my own and keep you >>> posted (may be >>> with some more specific/better questions on how to get this >>> behaviour from >>> Moose browsers). >>> >>> Cheers, >>> >>> Offray >>> >>> >>> >>> >>> -- >>> www.tudorgirba.com <http://www.tudorgirba.com> >>> >>> "Every thing has its own flow" >>> >> >> >> > > >

Sept. 13, 2014

Re: [Pharo-users] Fileouts line ending (^M and noeol in Vim)

by Carlo

You mean apart from changing the source in FileStream>>writeSourceCodeFrom:baseName:isSt: and adding fileStream wantsLineEndConversion: true; Don't think there is another simple way to get to this functionality. Cheers Carlo On 12 Sep 2014, at 5:26 PM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: Is there a way to change the default line ending of fileouts from mac to unix? Or alternatively... how to deal with current line endings in Vim? I'm using ":e ++ff=mac", then ":set ff=unix" and then saving it again. But there may be a better way. Thank you! Esteban A. Maringolo <eol.png>

Sept. 12, 2014

Fileouts line ending (^M and noeol in Vim)

by Esteban A. Maringolo

Is there a way to change the default line ending of fileouts from mac to unix? Or alternatively... how to deal with current line endings in Vim? I'm using ":e ++ff=mac", then ":set ff=unix" and then saving it again. But there may be a better way. Thank you! Esteban A. Maringolo

Sept. 12, 2014

Re: [Pharo-users] Frame Buffer

by Alexandre Bergel

No idea, but this is interesting. Have you tried to simply open a FileReference on the frame buffer? I understood that devices files are plain normal files. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. On Sep 12, 2014, at 5:37 AM, Annick Fron <list(a)afceurope.com> wrote: > Any body knows how to map a frame buffer /dev/fb0 under linux to a morph ? > > Annick >

Sept. 12, 2014

Re: [Pharo-users] The fourth R

by Trygve Reenskaug

On 11.09.2014 19:43, kilon alios wrote: > "If the program is more complex than the user's mental model, the > program should be simplified." this where we diverge , my opinion is > "no you should not simplify the programm itself unless the programm is > doing something it does need or should not do and instead simplify the > interface with the user". > > by saying we "need complex solutions to complex problems" I am not > saying this what we should do I am saying this is the only thing we > can do. We have no choice, because the world we live in is incredible > complex. "Simplicity" is an illusion of the brain , its the way of the > brain of saying "I understand this". Take two simple things, walking > and talking. To you and me those things are incredible simple but it > takes the brain years to understand these concepts and it also takes a > lot of effort and a lot of failures and a pain. So they are not simple > at all, yet each time you walk you dont even think about it, you just > do it. Yes, the real world is complex.Humans have been trying to model it as long as humans have existed. The human arm is a complex multi-dimensional mechanism. Between the human arm and the robot arm there must be a human brain that designs the robot. If this design is expressed under a modeling paradigm that can be directly transcribed into the code for the control computer, then the code can be simple and easy to read for the person who understands the design. Douglas Engelbart, the inventor of the mouse, proposed that computers should be used to augment the human intellect. He is talking about man-machine symbiosis, not automation. > What you say about mapping to the mental model of the user is true , > its a way to implement simplicity the problem however is that the user > is not made to think as a coder and programming language and > development environment even as sophisticated as pharo are made for > coders. Even if those coders are kids. They are still coders and they > have to learn the coding philosophy. That takes years of practice like > walking and talking. So coding can never be truly simple. Yes and no. Like reading, coding is not simple. But the threshold to be low. That's why we need a new foundation for programming that is designed for general use. Smalltalk-72 was such a foundation, but it didn't scale to large problems. As I understand the history, Smalltalk-76 solved the scaling problem, but lost the kids. The challenge as I see it is to regain 'children of all ages' while keeping the scaling. This is a goal of DCI. > The only way you can create a software that maps to the mental model > of the average user is to create AI software that can communicate to > the user as if it was human. Then you have a simple enough interface > for your user but still the implementation will be extremely complex. AI is only way but not the only one. A computer can basically do three things: It can store data, it can transform data, and it can communicate data. Simple and powerful. I want this simplicity to follow through to the end user. > > Python is not easier because its more readable than Pharo its easier > because its fully documented, Pharo is not. Its also easier to use > because it comes with a great collection of libraries to fit many > diffirent needs , Pharo does not. Unfortunately those weakness are > closely related with the unpopularity of a language. Its unavoidable. > So I cannot recommend Pharo as easier to use than Python to a kid, > because it is not. > > I have also to state here that I am not a fan of belief that readable > code is very important, its important only if you want to change the > system but people rarely do. When it comes to personal code itself its > far easier to understand code based on documentation than it is to > read and also far faster.Of course the more readable is the code the > better. Psychologists say that people don't ask for something that they don't know exists. Apple has been very good at giving people new capabilities they had never missed. My favorite user, the computational chemist, uses many sophisticated applications and miss better facilities for integrating their use. > > But readability itself does not depend so much on the language as the > habbits of the coder itself. Its actually very easy to produce very > difficult to read code in both Python and Pharo. > > I also find that languages are not very important , they are important > because its the base on top of which one builds the software but they > are too abstract. Actually they are too abstract. So I find libraries > a lot more useful , powerful and the big reason why a language is easy > or not easy to use. Yes. We need a more concrete platform. > > Saying I love Pharo and I am incredible excited to be a contributor to > it , even though not a very active one. I want to see Pharo succeed > because for me Pharo is closer to the AI system I am dreaming of than > any other language out there and I really like its overall design. I > hope Pharo evolves not to another programming language but rather to a > human language and a human environment liberating the user from the > technicalities of the system. Pharo is small but is going to a very > promising direction. > > All hail Pharo :) > > On Thu, Sep 11, 2014 at 6:42 PM, Trygve Reenskaug <trygver(a)ifi.uio.no > <mailto:trygver@ifi.uio.no>> wrote: > > Hi kilon alios, > I want to go deeper than any programming language. "What is a > computer?" Almost all programming languages build on the von > Neumann architecture with data processing as " The execution of a > systematic sequence of operations > performed upon data." I believe this is unnecessarily low-level > and complex for general use. Much closer to the human mind is to > build on an object computer where the unit of storage is the > object rather than the bit or byte. Data processing becomes "the > systematic exchange of messages between objects." Lots of stuff > that's of no interest to the general user is then hidden under the > hood. > > The users of immediate importance may be power users. > Computational chemists are my favorite examples. What shall be > their mental model, what do we teach them and how do we form our > programs such that they can understand and modify what goes on on > the computer? > > I foresee that (virtual) object computers will supersede our > current computers for general programming. They will be supported > by experts doing systems programming on various levels from > virtual machines down to microcode and hardware. When this is > achieved; Java, Ruby, C++, C, Haxe, etc. will no longer be used > for general application programming. (Smalltalk is, of course, not > a language but an object computer.) > > The "pythonic" culture should permeate more than Phyton, it > should be behind all we do. Thanks for sharing it. > C. A. R. Hoare says it succintly: > " There are two ways of constructing a software design: > - One way is to make it so simple that there are obviously > no deficiencies > - The other way is to make it so complicated that there are > no obvious deficiencies." > and > "The first method is far more difficultâ¦." > also: > "The price of reliability is the pursuit of the utmost simplicity" > > I think we are in agreement about the need for readable code. But > I disagree when you say "We need very complex solutions to very > complex problems". I believe we can attain simple solutions to > very complex problems. If the complexity is in the user's mental > model then a direct mapping of this model into code will be simple > as seen from the user's point of view. If the program is more > complex than the user's mental model, the program should be > simplified. > > It would be helpful if you would suggest an example where Phyton > leads to more readable code than say Pharo. > > > > On 07.09.2014 12:29, kilon alios wrote: >> Python has no competition. Sure there are languages that are more >> popular than Python for their own reasons. There have been >> simpler languages before python, there have been more popular >> languages, more cross platform languages etc etc but Python fills >> a gap that no language was able to fill before it , easy to use >> very powerful well documented libraries. Python is a language >> that you can teach to a kid now and make a living later on using >> until his or her old age. Its not because the language is simple >> , its simple enough but not the simplest. Its because the culture >> surrounding the creation of libraries . That culture has a name >> its called "pythonic" >> >> Beautiful is better than ugly. >> Explicit is better than implicit. >> Simple is better than complex. >> Complex is better than complicated. >> Flat is better than nested. >> Sparse is better than dense. >> Readability counts. >> Special cases aren't special enough to break the rules. >> Although practicality beats purity. >> Errors should never pass silently. >> Unless explicitly silenced. >> In the face of ambiguity, refuse the temptation to guess. >> There should be one-- and preferably only one --obvious way to do it. >> Although that way may not be obvious at first unless you're Dutch. >> Now is better than never. >> Although never is often better than *right* now. >> If the implementation is hard to explain, it's a bad idea. >> If the implementation is easy to explain, it may be a good idea. >> Namespaces are one honking great idea -- let's do more of those! >> this kind of ideology is why Python has been so successful. It has also inspired jokes like this >> http://xkcd.com/353/ >> it may look funny and it says thinks about overestimating the simplicity of those libraries but python does feel at times as simple as this, as simple as importing antigravity. >> So if a kid comes to me and ask me "what language should I learn" , I will recommend a language that is fairly easy to learn , has powerful library , easy to use libraries , well documented and its a language that will able to keep using even if his or her needs change, forever. For that only Python is the language that has been able to succeed and I think its adoption will continue to progress in educational institutions pretty much everywhere on the planet. >> Referring to the rest of your post I dont agree that we need to separate Data from Code, I think quite opossite that a kid needs to be taught why Code and Data are one and what that means in practice. I also don't agree that OO or functional programming or any other programming paradigm I am aware of are the future. They are simple solutions for simpler times. The coding community at large the way I see it is in denial hoping to apply simple recipes to solve complex problems. We need very complex solutions to very complex problems , we need tools that can interact with the user in many diffirent ways. >> Pharo is definitely showing the future, the close integration of IDE , language and environment. But thats is just the start, the next step is powerful tools that can deeply interact with code and solve automagically logical coding problems. Obviously all that has to be wrapped to an easy enough interface for the user even if the solutions is very complex. >> Fortunately this where the rest of the coding world is heading. For example iPython is one of the most popular python projects right and it offers a highly interactive environment for python coders that shares a lot of similarities with Pharo though the implementation is very different. >> So the future is no longer languages , is no longer IDEs , its not even environments but tools that are produced in these environments that can vastly automate coding and hide the increasing complexity of coding solutions. Maybe one day a child will be able to describe to a computer what kind of software he or she needs and the computer automatically generate the code for it. That day is not close enough but is where we are heading. >> >> >> On Sun, Sep 7, 2014 at 12:34 PM, Trygve Reenskaug >> <trygver(a)ifi.uio.no <mailto:trygver@ifi.uio.no>> wrote: >> >> I have for some time been pondering two problems. One is to >> identify the fourth R in *R*eading, w*R*iting, a*R*ithmetic, >> and p*R*ogramming. There are many contenders for the kids' >> first step. I believe the English government has chosen >> Phyton as a first language. Scratch has a certain popularity, >> there are many others. My concern is "what comes next"? I >> want the kid to gradually build a mental model of what >> computing is all about. Learn a little, do a little, lean >> more, do more, etc. up do old age. This goes much deeper than >> any programming language. It's a bit as learning to read. >> Personally, I "broke the reading code"at an early age. Since >> then, I have been learning more and more. What I read today >> would have been incomprehensible to me 75 years ago. But my >> basic mental model of what reading is all about has remained >> unchanged. I have never had to unlearn anything. >> >> I suggest that true object orientation (not class >> orientation) can form the foundation for the human mental >> model of computing. Internalize it and live with it forever. >> ------------------------------------- >> The other problem is to find a better example for DCI >> presentations. It should >> >> 1. Be executable and have a cool demo effect. >> 2. Its domain model should be obvious from the demo. >> 3. It should have very few and very simple Data classes. >> 4. It should have a Context that is clearly and >> obviously separate from the Data. >> 5. It should scale to any number of Contexts (use cases) >> without changing the Data classes. >> >> ----------------------------------------- >> /Last night I got an idea for an example: A waltzing couple. >> (See the attached for a picture and Wikipedia for a movie of >> the use case)./ >> >> The program needs one simple class for a moveable shape and a >> DCI Context for each dance (waltz, foxtrot, tango, ... for >> two role, polonaise for more.) The example will clearly >> demonstrate the wisdom in separating what the system IS from >> what the system DOES since the simple Shape class would be >> overloaded with instance methods for all dances. >> >> What do you think? >> >> --Trygve >>

Sept. 12, 2014

Re: [Pharo-users] [Esug-list] How to contribute CP1251TextConverter ?

by Sven Van Caekenberghe

Adding CP1251 support to ZnByteEncoder comes down to adding one method (and adapting some initialization code): ZnByteEncoder class>>#cp1251Mapping "self generateByteToUnicodeSpec: ''http://unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP1251.TXT''" ^ #( 16r0402 16r0403 16r201A 16r0453 16r201E 16r2026 16r2020 16r2021 16r20AC 16r2030 16r0409 16r2039 16r040A 16r040C 16r040B 16r040F 16r0452 16r2018 16r2019 16r201C 16r201D 16r2022 16r2013 16r2014 nil 16r2122 16r0459 16r203A 16r045A 16r045C 16r045B 16r045F 16r00A0 16r040E 16r045E 16r0408 16r00A4 16r0490 16r00A6 16r00A7 16r0401 16r00A9 16r0404 16r00AB 16r00AC 16r00AD 16r00AE 16r0407 16r00B0 16r00B1 16r0406 16r0456 16r0491 16r00B5 16r00B6 16r00B7 16r0451 16r2116 16r0454 16r00BB 16r0458 16r0405 16r0455 16r0457 16r0410 16r0411 16r0412 16r0413 16r0414 16r0415 16r0416 16r0417 16r0418 16r0419 16r041A 16r041B 16r041C 16r041D 16r041E 16r041F 16r0420 16r0421 16r0422 16r0423 16r0424 16r0425 16r0426 16r0427 16r0428 16r0429 16r042A 16r042B 16r042C 16r042D 16r042E 16r042F 16r0430 16r0431 16r0432 16r0433 16r0434 16r0435 16r0436 16r0437 16r0438 16r0439 16r043A 16r043B 16r043C 16r043D 16r043E 16r043F 16r0440 16r0441 16r0442 16r0443 16r0444 16r0445 16r0446 16r0447 16r0448 16r0449 16r044A 16r044B 16r044C 16r044D 16r044E 16r044F ) All in all it is just a 128 slot Array constant. I will start another thread asking for which encodings people want to add. On 12 Sep 2014, at 14:39, stepharo <stepharo(a)free.fr> wrote: >> >> Thank you Damien for reposting my question here and for guiding me here. >> >> Following the Stef's reccomendations, converter is now published as separate >> package here: http://ss3.gemstone.com/ss/CP1251TextConverter.html >> >> But I do not get an answer I'm seeking for yet. >> >> I want/seeking the way for this converter to be included in standard Pharo >> distribution. Smalltalk has small but consistent Russian community, so it' >> looks reasonable, especially taking into account that we have >> RussianEnvironment anyway. > > Yuri we would prefer to have a strong package maintained outside of Pharo. > Why because we are trying to reduce and remove code from Pharo. > What we can do is to offer you an account to our automatic build server. > Based on it you could load a configuration (ConfigurationOfRussianPharo) and provide > this image to the people requiring russian support. > It would be good that you evaluate the solution proposed by Sven to avoid duplication of effort. >> Plus, I want to use this simple and small example to understand a process of >> including my code in "mainstream" and get understand the possible problems. > Here is the process for enhancement to Pharo > - signing the license agreement (see www.pharo.org) > - opening a bug or enhancement request on fogbugz > https://pharo.fogbugz.com > - proposing changes with tests that get reviewed by the community > > For magritte and Glorp you should contact the package maintainer. > Each project on SmalltalkHub has now a public inbox. So I would publish my changes there >> Working on SmallPOS I made a lot of adjusments in "Pharo Core", Magritte and >> GLORP, which probably may be useful outside the SmallPOS. So I started a >> process of separating this code from SmallPOS package and want to know how >> to share it. >> >> >>> Currently it does CP1250, CP1252 and CP1253 among others (including >>> KOI8R), but not (yet) CP1251. >> Sven, abstractly, it will be better to include CP1251. After all, it's >> little bit strange to have KOI8R implemented without implementing CP1251. >> Second one is widely used - much wider then KOI8R. I was forced to use it as >> hardware I use (sticker label printer and cash register) was designed to use >> CP1251 at hardware level. As far as it takes no or little efforts I propose >> you to add the mentioned encoding. > > Good. You see when we do not get confronted with a problem it is difficult to react > adequately :) >> >> >>> Do you see http://www.squeaksource.com/RussianSupport.html >> No, I dont. When I implemented mine one - it was several years ago - I tried >> to find one, but failed. Repo you pointing me to was made far before mine, >> so it was possible to find it. I don't know why I failed to find it. I may >> assume that, probably, I found it but it is not working. You see, it looks >> like it designed for Squeak, or, at least, the author do not follow the >> template other ByteTextConverters follow. Just a speculation, I do not tried >> to load it now. >> > > This is why I suggest: > - publish on SmalltalkHub > - create a configuration with meta data. > - publish it to MetaRepoForPharo30 > - your package will be available on > https://ci.inria.fr/pharo-contribution/job/PharoProjectCatalog/HTML_Report/? > > soon we will have a public web site catalog.Pharo.org

Sept. 12, 2014

Re: [Pharo-users] [Esug-list] How to contribute CP1251TextConverter ?

by stepharo

> Thank you Damien for reposting my question here and for guiding me here. > > Following the Stef's reccomendations, converter is now published as separate > package here: http://ss3.gemstone.com/ss/CP1251TextConverter.html > > But I do not get an answer I'm seeking for yet. > > I want/seeking the way for this converter to be included in standard Pharo > distribution. Smalltalk has small but consistent Russian community, so it' > looks reasonable, especially taking into account that we have > RussianEnvironment anyway. Yuri we would prefer to have a strong package maintained outside of Pharo. Why because we are trying to reduce and remove code from Pharo. What we can do is to offer you an account to our automatic build server. Based on it you could load a configuration (ConfigurationOfRussianPharo) and provide this image to the people requiring russian support. It would be good that you evaluate the solution proposed by Sven to avoid duplication of effort. > Plus, I want to use this simple and small example to understand a process of > including my code in "mainstream" and get understand the possible problems. Here is the process for enhancement to Pharo - signing the license agreement (see www.pharo.org) - opening a bug or enhancement request on fogbugz https://pharo.fogbugz.com - proposing changes with tests that get reviewed by the community For magritte and Glorp you should contact the package maintainer. Each project on SmalltalkHub has now a public inbox. So I would publish my changes there > Working on SmallPOS I made a lot of adjusments in "Pharo Core", Magritte and > GLORP, which probably may be useful outside the SmallPOS. So I started a > process of separating this code from SmallPOS package and want to know how > to share it. > > >> Currently it does CP1250, CP1252 and CP1253 among others (including >> KOI8R), but not (yet) CP1251. > Sven, abstractly, it will be better to include CP1251. After all, it's > little bit strange to have KOI8R implemented without implementing CP1251. > Second one is widely used - much wider then KOI8R. I was forced to use it as > hardware I use (sticker label printer and cash register) was designed to use > CP1251 at hardware level. As far as it takes no or little efforts I propose > you to add the mentioned encoding. Good. You see when we do not get confronted with a problem it is difficult to react adequately :) > > >> Do you see http://www.squeaksource.com/RussianSupport.html > No, I dont. When I implemented mine one - it was several years ago - I tried > to find one, but failed. Repo you pointing me to was made far before mine, > so it was possible to find it. I don't know why I failed to find it. I may > assume that, probably, I found it but it is not working. You see, it looks > like it designed for Squeak, or, at least, the author do not follow the > template other ByteTextConverters follow. Just a speculation, I do not tried > to load it now. > This is why I suggest: - publish on SmalltalkHub - create a configuration with meta data. - publish it to MetaRepoForPharo30 - your package will be available on https://ci.inria.fr/pharo-contribution/job/PharoProjectCatalog/HTML_Report/? soon we will have a public web site catalog.Pharo.org

Sept. 12, 2014

Re: [Pharo-users] Is anyone interested in developing a package for Google's Data API?

by Andy Burnett

á§ Sven said <<< Hi Andy, I think we have all the building blocks to do this (ZnClient from Zinc, HTTPS from Zodiac, OAuth2 from Zinc-SSO, JSON from NeoJSON), so that is good. But there are a large number of Google APIs ( https://developers.google.com/gdata/docs/directory) each of them containing lots of functionality. There are deprecation warnings on some of them. It is of course necessary to first fully familiarise oneself with each of them and the application they connect to. When some basic calls work, the next step would indeed be to make nice object models for each of them. Some people on this list have built these kinds of API before (like Sean's Flicker Client). I also think that once one of them is done, others could be implemented by many different people, like students. >>> Yup, I totally agree. We have most of the pieces, and we just need a project to assemble them. My suggestion is that we focus on the Spreadsheet services first. This seems to be the most flexible/useful one. Once that is working, we could develop the other packages. So, would anyone like to take up this project? Cheers Andy

Sept. 12, 2014