January 2017 - Pharo-users - lists.pharo.org

Help required in refreshing MenuModel

by Jigyasa Grover

Hi I have been building a Pharo UI using Spec. I utilized *MenuModel* for building a *menu*, and now I want to refresh the *menu*after an item in it has been clicked. For example: I click *option1* in *menu* and some other item (say *option2*) in *menu* changes to *option3*. I hope my question is clear. I tried: -- /menu autoRefresh: true./ I was planning to use the /initializePresenter/ method, but am stuck currently. Help appreciated. Best Jigyasa -- View this message in context: http://forum.world.st/Help-required-in-refreshing-MenuModel-tp4930086.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Jan. 20, 2017

<Programming> 2017: Final call for workshop, symposium, demo & poster submissions

by Tim Molderez

----------------------------------------------------------------------- <Programming> 2017 : The Art, Science, and Engineering of Programming April 3-6, 2017, Brussels, Belgium http://2017.programming-conference.org ----------------------------------------------------------------------- Final call for submissions to all co-located events at the <Programming> 2017 conference: - ELS 2017 - 10th European Lisp Symposium - Modularity 2017 Invited talks - International Symposium on Modularity - **Updated** ACM Student Research Competition / <Programming> 2017 Posters - **NEW** <Programming> 2017 Demos - **NEW** CoCoDo 2017 - Raincode Labs Compiler Coding Dojo - LASSY 2017 - 2nd Workshop on Live Adaptation of Software SYstems - **NEW** MiniPLoP 2017 - Mini Pattern Languages of Programs writers' workshop - **Updated** MOMO 2017 - 2nd Workshop on Modularity in Modelling - MoreVMs 2017 - 1st Workshop on Modern Language Runtimes, Ecosystems, and VMs - PASS 2017 - 1st Workshop on Programming Across the System Stack - PX 2017 - 2nd Workshop on Programming Experience - ProWeb 2017 - 1st Workshop on Programming Technology for the Future Web - Salon des RefusÃ©s 2017 - 1st edition of the Salon des RefusÃ©s workshop All co-located events will take place during April 3-4 2017. CFPs for each of these events are listed below. (apart from Modularity 2017, which is invitation-based) **************************************************************** ELS 2017 - 10th European Lisp Symposium Submissions: Mon 30 Jan 2017 Notifications: Mon 27 Feb 2017 Symposium date: Mon Apr 3 - Tue Apr 4 2017 http://2017.programming-conference.org/track/els-2017 **************************************************************** The purpose of the European Lisp Symposium is to provide a forum for the discussion and dissemination of all aspects of design, implementation and application of any of the Lisp and Lisp-inspired dialects, including Common Lisp, Scheme, Emacs Lisp, AutoLisp, ISLISP, Dylan, Clojure, ACL2, ECMAScript, Racket, SKILL, Hop and so on. We encourage everyone interested in Lisp to participate. The 10th European Lisp Symposium invites high quality papers about novel research results, insights and lessons learned from practical applications and educational perspectives. We also encourage submissions about known ideas as long as they are presented in a new setting and/or in a highly elegant way. Topics include but are not limited to: * Context-, aspect-, domain-oriented and generative programming * Macro-, reflective-, meta- and/or rule-based development approaches * Language design and implementation * Language integration, inter-operation and deployment * Development methodologies, support and environments * Educational approaches and perspectives * Experience reports and case studies ******************************************************************** ACM Student Research Competition / <Programming> 2017 Posters Submissions **extended** : Mon 30 Jan 2017 http://2017.programming-conference.org/track/programming-posters ******************************************************************** The ACM Student Research Competition (SRC), sponsored by Microsoft Research, offers a unique forum for ACM student members at the undergraduate and graduate levels to present their original research before a panel of judges and conference attendees. The SRC gives visibility to up-and-coming young researchers, and offers them an opportunity to discuss their research with experts in their field, get feedback, and to help sharpen communication and networking skills. ACMâs SRC program covers expenses up to $500 for all students invited to an SRC. See our website for requirements and further details. Please note that, while the SRC involves a poster session, there also is a regular poster session that isn't part of a competition. Submissions for this regular session are due March 3rd. *********************************************************************** â¹Programmingâº 2017 Demos Submissions: Fri 3 Mar 2017 http://2017.programming-conference.org/track/programming-2017-Demos *********************************************************************** Demonstrations will be selected on the basis of technical merit, relevance, and novelty of presentation at <Programming>. They can include work in progress, commercial or in-house applications, proofs of concept, results of academic or industrial research, or any other innovative programming tools or systems. We encourage authors of accepted papers to co-located workshops and main conferences also submit a demo proposal. We hope that this will give them the opportunity to show their work in action, and increase the visibility of their results. We suggest to cite the paper in the demo abstract. **************************************************************** CoCoDo 2017 - Raincode Labs Compiler Coding Dojo Coding dojo date: Tue 4 Apr 2017 https://cocodo.github.io **************************************************************** CoCoDo is a coding dojo where you can enjoy an entire day of compiler programming under gentle guidance of field experts. Compiler construction comprises, but is not limited to, lexical analysis, syntactic analysis, preprocessing, context handling, code generation, code optimisation, virtual machines, interpreters, smell detection, clone management, portability, migration, refactoring, domain-specific language design, linking and loading, assembling and disassembling, generics and reflection, numerous paradigms and so much more. If you are interested in participating, please contact Vadim Zaytsev: vadim(a)raincodelabs.com ****************************************************************** LASSY 2017 - 2nd Workshop on Live Adaptation of Software SYstems Submissions: Fri 3 Feb 2017 Notifications: Fri 3 Mar 2017 Workshop date: Mon 3 Apr 2017 http://2017.programming-conference.org/track/LASSY-2017-papers ****************************************************************** When developing current-day software systems, their deployment and usage environments should be considered carefully, in order to understand the adaptations those systems might need to undergo to interact with other systems and with their environment. Moreover, due to the portability, mobility and increasingly evolutionary nature of software systems, such adaptations should be enacted even while the system is running. Developing such software systems can prove challenging, and many seemingly different techniques to address this concern have been proposed over the last couple of years. The intention of the LASSY workshop is to congregate all topics relevant to dynamic adaptation and run-time evolution of software systems, ranging from a computer science perspective covering the domains of programming languages, model-driven software development, software and service composition, context-aware databases, software variability, requirements engineering, UI adaptation and other domains, to a human perspective covering sociological or ethical implications of dynamic software systems. The workshop provides a space for discussion and collaboration between researchers working on the problem of enabling live adaptations to software systems, across the development stack. Topics of Interest: * Design and Implementation of Live Adaptive Software Systems * Context-, aspect-, feature-, role- and agent-oriented programming * Context representation and discovery * Context-aware model-driven software development * Context-aware data management * Software variability and dynamic product lines * Self-adaptive, self-explanatory systems * Inconsistency management, verification, and validation * Middleware and Runtime of Live Adaptive Software Systems * Dynamic software evolution, upgrades and configuration * Dynamic software and service composition mechanisms * Dynamic software architecture and middleware approaches * Dynamic user interface adaptation and multimodal user interfaces * Impact and Assessment of Live Adaptive Software Systems * User acceptance and usability issues * Human, sociological, ethical and legal aspects * Privacy and security aspects of dynamic adaptability * Live adaptation in smart environments (e.g. smart rooms, smart robot cells, smart factories, smart cities) * Self-adaptation and emergence in SoS and CPSoS ********************************************************************** MiniPLoP 2017 - Mini Pattern Languages of Programs writers' workshop Workshop date: Mon 3 Apr 2017 http://2017.programming-conference.org/track/MiniPLoP-2017-papers ********************************************************************** Software developers and those involved with programming have long observed that certain patterns recur and endure across different applications and systems. The growing interest in Design Patterns, Architectural Patterns, Analysis Patterns, Pedagogical Patterns, Agile Patterns, and so on, represents an effort to catalog and better communicate knowledge, providing handbooks of proven solutions to common problems. The MiniPLoP writers' workshop brings together researchers, educators, and practitioners whose interests span a remarkably broad range of topics and who share an interest in exploring the power of the pattern form. MiniPLoP invites you to add your expertise to the growing corpus of patterns. MiniPLoP focuses on improving the expression of patterns. You will have the opportunity to refine and extend your patterns or pattern ideas with the help from knowledgeable and sympathetic fellow pattern enthusiasts. You will also be able to discuss applications of patterns in industry and academia. Techniques for Pattern Mining will also be presented. Highlights include group discussions on patterns, an introduction to pattern writing, an international keynote, and the writersâ workshop. This MiniPLoP at <Programming> 2017 has the goal to help beginners learn more about the pattern community. If you have some patterns or pattern ideas you would like to have brainstormed or workshopped, please contact the organizers at: miniplop2017(a)hillside.net **************************************************************** MOMO 2017 - 2nd Workshop on Modularity in Modelling Abstract submissions (optional) **extended** : Sun Feb 5 2017 Paper submissions **extended** : Sun Feb 12 2017 Notifications: Wed Feb 22 2017 Workshop date: Mon 3 Apr 2017 http://www.momo2017.ece.mcgill.ca/cfp.htm **************************************************************** Extending the time-honored practice of separation of concerns, Model-Driven Engineering (MDE) promotes the use of separate models to address the various concerns in the development of complex software-intensive systems. The main objective is to choose the right level of abstraction to modularize a concern, specify its properties and reason about the system under development depending on stakeholder and development needs. While some of these models can be defined with a single modelling language, a variety of heterogeneous models and languages are typically used in the various phases of software development. Furthermore, Domain-Specific Modelling Languages designed to address particular concerns are also increasingly used. Despite the power of abstraction of modelling, models of real-world problems and systems quickly grow to such an extent that managing the complexity by using proper modularization techniques becomes necessary. As a result, many (standard) modelling notations have been extended with aspect-oriented mechanisms and advanced composition operators to support advanced separation of concerns, to combine (possibly heterogeneous) models modularizing different concerns, to execute an application based on modularized models, and to reason over global properties of modularized models. The Second International Modularity in Modelling Workshop brings together researchers and practitioners interested in the theoretical and practical challenges resulting from applying modularity, advanced separation of concerns, and advanced composition at the modelling level. It is intended to provide a forum for presenting new ideas and discussing the impact of the use of modularization in the context of MDE at different levels of abstraction. We are interested in submissions on all topics related to modularity and modelling including but not limited to: * Modularization Support in Modelling Languages and Tools * Model Interfaces * Homogeneous Model Composition Operators * Heterogeneous Model Composition Operators * Visualization of Modularized and Composed Models * Effects of Using Modularization and Composition in Modelling * On Verification and Validation * On Reuse * On the Model-Driven Software Development Process (Requirements Engineering, Software Architecture, Software Design, Implementation) * On Maintenance * Experience Reports / Empirical Evaluations of Applying Modularization and Composition in Modelling * Feature-Oriented, Aspect-Oriented and Concern-Oriented Modelling * Modularization support and composition operators for specific modelling notations * Modelling essential characteristics of specific (crosscutting) concerns * Multi-View Modelling: avoiding inconsistencies, avoiding Redundancies * Support for Detecting and/or Resolution of Feature Interactions * Domain-Specific Modelling * Modularization for Domain-Specific Languages * Composition for Domain-Specific Languages * Domain-specific Aspect Models ****************************************************************************** MoreVMs 2017 - 1st Workshop on Modern Language Runtimes, Ecosystems, and VMs Submissions: Wed 15 Feb 2017 Notifications: Wed 1 Mar 2017 Workshop date: Mon 3 Apr 2017 http://2017.programming-conference.org/track/MoreVMs-2017-papers ****************************************************************************** The main goal of the workshop is to bring together both researchers and practitioners and facilitate effective sharing of their respective experiences and ideas on how languages and runtimes are utilized and where they need to improve further. We welcome presentation proposals in the form of extended abstracts discussing experiences, work-in-progress, as well as future visions from the academic as well as industrial perspective. Relevant topics include, but are definitely not limited to, the following: * Extensible VM design (compiler- or interpreter-based VMs) * Reusable runtime components (e.g. interpreters, garbage collectors, intermediate representations) * Static and dynamic compiler techniques * Techniques for compilation to high-level languages such as JavaScript * Runtimes and mechanisms for interoperability between languages * Tooling support (e.g. debugging, profiling, etc.) * Programming language development environments and virtual machines * Case studies of existing language implementations, virtual machines, and runtime components (e.g. design choices, tradeoffs, etc.) * Language implementation challenges and trade-offs (e.g. performance, completeness, etc.) * Surveys and applications usage reports to understand runtime usage in the wild * Surveys on frameworks and their impact on runtime usage * New research ideas on how we want to build languages in the future ************************************************************************** PASS 2017 - 1st Workshop on Programming Across the System Stack Submissions: Mon 13 Feb 2017 Notifications: Mon 27 Feb 2017 Workshop date: Tue 4 Apr 2017 http://2017.programming-conference.org/track/PASS-2017#Call-for-Papers ************************************************************************** The landscape of computation platforms has changed dramatically in recent years. Emerging systems - such as wearable devices, smartphones, unmanned aerial vehicles, Internet of things, cloud computing servers, heterogeneous clusters, and data centers - pose a distinct set of system-oriented challenges ranging from data throughput, energy efficiency, security, real-time guarantees, to high performance. In the meantime, code quality, such as modularity or extensibility, remains a cornerstone in modern software engineering, bringing in crucial benefits such as modular reasoning, program understanding, and collaborative software development. Current methodologies and software development technologies should be revised in order to produce software to meet system-oriented goals, while preserving high internal code quality. The role of the Software Engineer is essential, having to be aware of the implications that each design, architecture and implementation decision has on the application system ecosystem. This workshop is driven by one fundamental question: How does internal code quality interact with system-oriented goals? We welcome both positive and negative responses to this question. An example of the former would be modular reasoning systems specifically designed to promote system-oriented goals, whereas an example of the latter would be anti-patterns against system-oriented goals during software development. Areas of interest include but are not limited to: * Energy-aware software engineering (e.g. energy efficiency models, energy efficiency as a quality attribute) * Modularity support (e.g., programming language design, development tools or verification) for applications in resource-constrained or real-time systems * Emerging platforms (e.g., Internet of Things and wearable devices) * Security support (e.g., compositional information flow, compositional program analysis) * Software architecture for reusability and adaptability in systems and their interactions with applications * Empirical studies (patterns and anti-patterns) on the relationship between internal code quality and system-oriented goals * Software engineering techniques to balance the trade-off between internal code quality and efficiency * Memory bloats and long-tail performance problems across modular boundaries * Program optimization across modular boundaries * Internal code quality in systems software * Reasoning across applications, compilers, and virtual machines **************************************************************** PX 2017 - 2nd Programming Experience Workshop Submissions: Sat 4 Feb 2017 Notifications: Mon 27 Feb 2017 Workshop date: Mon 3 Apr 2017 http://programming-experience.org/px17 **************************************************************** Imagine a software development task: some sort of requirements and specification including performance goals and perhaps a platform and programming language. A group of developers head into a vast workroom. In that room they discover they need to explore the domain and the nature of potential solutionsâthey need exploratory programming. The Programming Experience Workshop is about what happens in that room when one or a couple of programmers sit down in front of computers and produce code, especially when itâs exploratory programming. Do they create text that is transformed into running behavior (the old way), or do they operate on behavior directly (âlivenessâ); are they exploring the live domain to understand the true nature of the requirements; are they like authors creating new worlds; does visualization matter; is the experience immediate, immersive, vivid and continuous; do fluency, literacy, and learning matter; do they build tools, meta-tools; are they creating languages to express new concepts quickly and easily; and curiously, is joy relevant to the experience? Correctness, performance, standard tools, foundations, and text-as-program are important traditional research areas, but the experience of programming and how to improve and evolve it are the focus of this workshop, and in this edition we would like to focus on exploratory programming. The technical topics include: * Exploratory programming * Live programming * Authoring * Representation of active content * Visualization * Navigation * Modularity mechanisms * Immediacy * Literacy * Fluency * Learning * Tool building * Language engineering ************************************************************************* ProWeb 2017 - 1st Workshop on Programming Technology for the Future Web Submissions: Wed 15 Feb 2017 Notifications: Wed 1 Mar 2017 Workshop date: Tue 4 Apr 2017 http://2017.programming-conference.org/track/proweb-2017-papers ************************************************************************* Full-fledged web applications have become ubiquitous on desktop and mobile devices alike. Whereas âresponsiveâ web applications already offered a more desktop-like experience, there is an increasing demand for ârichâ web applications (RIAs) that offer collaborative and even off-line functionality âGoogle docs being the prototypical example. Long gone are the days that web servers merely had to answer incoming HTTP request with a block of static HTML. Todayâs servers react to a continuous stream of events coming from JavaScript applications that have been pushed to clients. As a result, application logic and data is increasingly distributed. Traditional dichotomies such as âclient vs. serverâ and âoffline vs. onlineâ are fading. The 1st International Workshop on Programming Technology for the Future Web, or ProWeb17, is a forum for researchers and practitioners to share and discuss new technology for programming these and future evolutions of the web. We welcome submissions introducing programming technology (i.e., frameworks, libraries, programming languages, program analyses and development tools) for implementing web applications and for maintaining their quality over time, as well as experience reports about the use of state-of-the-art programming technology. Relevant topics include, but are not limited to: * Quality on the new web: static and dynamic program analyses; code, design test and process metrics; development and migration tools; automated testing and test generation; contract systems, type systems, and web service API conformance checking; â¦ * Hosting languages on the web: new runtimes; transpilation or compilation to JavaScript, WebAssembly, asm.js, â¦ * Designing languages for the web: multi-tier (or tierless) programming; reactive programming; frameworks for multi-tier or reactive programming on the web; â¦ * Distributed data sharing, replication and consistency: cloud types, CRDTs, eventual consistency, offline storage, peer-to-peer communication, â¦ * Security on the web: client-side and server-side security policies; policy enforcement; proxies and membranes; vulnerability detection; dynamic patching, â¦ * Surveys and case studies using state-of-the-art web technology (e.g., WebAssembly, WebSocket, LocalStorage, AppCache, ServiceWorkers, Meteor, deepstream.io, Angular.js, React and React Native, Swarm.js, Caja, TypeScript, Proxies, ClojureScript, Amber Smalltalk, Scala.js, â¦) * Ideas on and experience reports about: how to reconcile the need for quality with the need for agility on the web; how to master and combine the myriad of tier-specific technologies required to develop a web application, â¦ * Position statements on what the future of the web will look like **************************************************************** Salon des RefusÃ©s 2017 Submissions: Wed 1 Feb 2017 Notifications: Fri 17 Feb 2017 Workshop date: Tue 4 Apr 2017 https://refuses.github.io **************************************************************** Salon des RefusÃ©s (âexhibition of rejectsâ) was an 1863 exhibition of artworks rejected from the official Paris Salon. The jury of Paris Salon required near-photographic realism and classified works according to a strict genre hierarchy. Paintings by many, later famous, modernists such as Ãdouard Manet were rejected and appeared in what became known as the Salon des RefusÃ©s. This workshop aims to be the programming language research equivalent of Salon des RefusÃ©s. We provide a venue for exploring new ideas and new ways of doing computer science. Many interesting ideas about programming might struggle to find space in the modern programming language research community, often because they are difficult to evaluate using established evaluation methods (be it proofs, measurements or controlled user studies). As a result, new ideas are often seen as âunscientificâ. This workshop provides a venue where such interesting and thought-provoking ideas can be exposed to critical evaluation. Submissions that provoke interesting discussion among the program committee members will be published together with an attributed review that presents an alternative position, develops additional context or summarizes discussion from the workshop. This means of engaging with papers not just enables explorations of novel programming ideas, but also encourages new ways of doing computer science. Topics of interest The scope of the workshop is determined more by the format of submissions than by the specific area of programming language or computer science research that we are interested in. We welcome submissions in a format that makes it possible to think about programming in a new way, including, but not limited to: * Thought experiments â we believe that thought experiments, analogies and illustrative metaphors can provide novel insights and inspire fruitful programming language ideas. * Experimentation â we find prejudices in favour of theory, as far back as there is institutionalized science, but programming can often be seen more as experimentation than as theorizing. We welcome interesting experiments even if there is yet no overarching theory that explains why they happened. * Paradigms â all scientific work is rooted in a scientific paradigm that frame what questions can be asked. We encourage submissions that reflect on existing paradigms or explore alternative scientific paradigms. * Metaphors, myths and analogies â any description of formal, mathematical, quantitative or even poetical nature still represents just an analogy. We believe that fruitful ideas can be learned from less common forms of analogies as well as from the predominant, formal and mathematical ones. * From jokes to science fiction â a story or an artistic performance may explore ideas and spark conversations that provide crucial inspiration for development of new computer science thinking.

Jan. 20, 2017

Re: [Pharo-users] Usability issue with Pharo 5

by Hilaire

...another one In an implementor view, when selecting a method in the top list, then clicking somewhere in the text view, the carret does not follow, you have to clic again! Another regression compare to Pharo3. -- Dr. Geo http://drgeo.eu

Jan. 20, 2017

Usability issue with Pharo 5

by Hilaire

Playing with Pharo5 with Phratch, I just noted two usability problems: - Short cut for class ref does not work (CTRL+SHIFT+B) - selecting a word by double clicking in text editor is not as good as before, you need to be fast on your double click. It worked as a charm with Pharo 3. - when right clicking on a class name, you may lose the source code view on the bottom, it is a 1/2 event It is depressing to see these usability regressions release after release... -- Dr. Geo http://drgeo.eu -- Dr. Geo http://drgeo.eu

Jan. 20, 2017

Re: [Pharo-users] [Seaside] Bad Request ZnEntityTooLarge

by Johan Brichau

Hi Bernhard, imho, itâs better practice to detect too large file upload in your app on the client side, i.e. before your user has been uploading xxx MB. For that, you can check out various client-side programs like jQuery-FileUpload (https://blueimp.github.io/jQuery-File-Upload/ <https://blueimp.github.io/jQuery-File-Upload/>) You also might want to check out this: http://jbrichau.github.io/blog/large-file-upload-in-seaside <http://jbrichau.github.io/blog/large-file-upload-in-seaside> And Nickâs original post has come back online since I wrote mine too: http://nickager.com/blog/2011/07/01/File-upload-using-Nginx-and-Seaside <http://nickager.com/blog/2011/07/01/File-upload-using-Nginx-and-Seaside> The adaptor framework was built to minimize dependencies between Seaside and the http server. To make Seaside aware about an error occurring inside the http server, and allow to produce a response to it, a specialized extension of the adaptor is necessary. I think you _can_ make a nice looking page using Seaside when you tell Zinc that it should respond to the error using Seaside. Both Zinc and Seaside are frameworks and you can customize them by specializing appropriate methods. If you create your own ZnSeasideServerAdaptorDelegate and override #handleRequest: to catch the error, you can dispatch to the Seaside framework to render a nice looking page. There are several ways to dispatch back to Seaside. The easiest way would be to generate a generic page using the WABuilder: WAHtmlCanvas builder render: [ :html | html text: âOopsâ¦ entity too large!â ] However, that does not dispatch back to your running app and you probably expect to be able to specify some other callback in your Seaside code that would execute on that error? This would make your app dependent on Zinc though (and the Seaside framework would need be extended to handle that additional dependency on adaptors). Not sure if all that work makes sense when this kind of upload error is preferably handled differently. cheers Johan > On 20 Jan 2017, at 07:04, Bernhard Pieber <bernhard(a)pieber.com> wrote: > > Thank you for your answer, Sven. > > Thatâs a bummer. If I understand you correctly, currently there is no hook in Seaside to catch lower level server exceptions (like ZnEntityTooLarge) to show a nice looking error page, e.g. âYou are trying to upload a file thatâs too large. Donât do that!â Really? :-/ > > Cheers, > Bernhard > >> Am 19.01.2017 um 14:29 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: >> >> Hi Bernard, >> >> Your analysis is correct. >> >> Most Seaside adaptors, including ZnZincServerAdaptor, are implemented so that the incoming (Zn) request is read from the wire, then converted to Seaside WA* objects, processed, the result converted from WA* objects to an outgoing (Zn) response and put on the wire. >> >> Zn has some built-in resource protection measures, including a limit on how large entities (bodies) can be. The error of crossing such a limit is raised in the very first step, outside the scope of your Seaside handling code. >> >> At first sight, I would not immediately know how this can be solved. >> >> Note that in order to know how much is coming in, you have to read it, but you have to stop in time. Note also that the content-length header could be absent or wrong (a malicious request). >> >> I can't remember where we currently stand on a streaming Zn Seaside adaptor, there were some experiments in the past IIRC. That could be a solution, because then the entity/body is not read until further down the line, if we can get it to work. The current one only seems to do streaming for responses. >> >> Sven >> >>> On 19 Jan 2017, at 13:32, Bernhard Pieber <bernhard(a)pieber.com> wrote: >>> >>> I have a Seaside application which includes a file upload feature. >>> >>> renderContentOn: html >>> â¦ >>> html fileUpload >>> callback: [ :file | self receiveFile: file ]. >>> html submitButton: 'Uploadâ ] >>> â¦ >>> >>> In receiveFile: I just save the uploaded file on the file system. >>> >>> When I upload a file larger than 16 MB an error page is shown with the error message: >>> Bad Request ZnEntityTooLarge >>> >>> I found that by using ZnConstants>>maximumEntitySize: I can increase this limit. However, I want to catch this in the image and show an error message to the user. >>> >>> I tried wrapping receiveFile: and renderContentOn: with an on:do: exception handler for ZnEntityTooLarge. However, neither works. It seems that the error happens before renderContentOn: is even called. I searched the mailing lists but did not come up with an answer. >>> >>> How can I achieve this in Seaside? Any help would be much appreciated. >>> >>> Cheers, >>> Bernhard >>> _______________________________________________ >>> seaside mailing list >>> seaside(a)lists.squeakfoundation.org >>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >> >> > > _______________________________________________ > seaside mailing list > seaside(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Jan. 20, 2017

Re: [Pharo-users] [Seaside] Bad Request ZnEntityTooLarge

by Bernhard Pieber

Thank you for your answer, Sven. Thatâs a bummer. If I understand you correctly, currently there is no hook in Seaside to catch lower level server exceptions (like ZnEntityTooLarge) to show a nice looking error page, e.g. âYou are trying to upload a file thatâs too large. Donât do that!â Really? :-/ Cheers, Bernhard > Am 19.01.2017 um 14:29 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > > Hi Bernard, > > Your analysis is correct. > > Most Seaside adaptors, including ZnZincServerAdaptor, are implemented so that the incoming (Zn) request is read from the wire, then converted to Seaside WA* objects, processed, the result converted from WA* objects to an outgoing (Zn) response and put on the wire. > > Zn has some built-in resource protection measures, including a limit on how large entities (bodies) can be. The error of crossing such a limit is raised in the very first step, outside the scope of your Seaside handling code. > > At first sight, I would not immediately know how this can be solved. > > Note that in order to know how much is coming in, you have to read it, but you have to stop in time. Note also that the content-length header could be absent or wrong (a malicious request). > > I can't remember where we currently stand on a streaming Zn Seaside adaptor, there were some experiments in the past IIRC. That could be a solution, because then the entity/body is not read until further down the line, if we can get it to work. The current one only seems to do streaming for responses. > > Sven > >> On 19 Jan 2017, at 13:32, Bernhard Pieber <bernhard(a)pieber.com> wrote: >> >> I have a Seaside application which includes a file upload feature. >> >> renderContentOn: html >> â¦ >> html fileUpload >> callback: [ :file | self receiveFile: file ]. >> html submitButton: 'Uploadâ ] >> â¦ >> >> In receiveFile: I just save the uploaded file on the file system. >> >> When I upload a file larger than 16 MB an error page is shown with the error message: >> Bad Request ZnEntityTooLarge >> >> I found that by using ZnConstants>>maximumEntitySize: I can increase this limit. However, I want to catch this in the image and show an error message to the user. >> >> I tried wrapping receiveFile: and renderContentOn: with an on:do: exception handler for ZnEntityTooLarge. However, neither works. It seems that the error happens before renderContentOn: is even called. I searched the mailing lists but did not come up with an answer. >> >> How can I achieve this in Seaside? Any help would be much appreciated. >> >> Cheers, >> Bernhard >> _______________________________________________ >> seaside mailing list >> seaside(a)lists.squeakfoundation.org >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > >

Jan. 20, 2017

Couple grafoscopio notes

by Peter Uhnak

Hi, I've started playing around with grafoscopio, I am happy that I can finally organize all those little scripts and not lose them all the time. :) However there are couple of issues and notes I've ran into (don't worry about fixing them in any timely fashion, it is not blocking me) 1. For saving `UITheme builder` is used, but the correct approach is via `UIManager default` * this has obvious impact if the UIManager is different (UIManager has reference to UITheme, but not the other way around) To see all the calls, you can do this (or find the uses manually) calls := UITheme allCallsOn select: [ :each | each package name = #Grafoscopio ]. SystemNavigation default browseMessageList: calls name: 'Users of class UITheme' autoSelect: 'UITheme builder'. 2. Typo "Add nodo" -> "Add node" 3. "Move up|down node" -> "Move node up|down" (to be consistend with the rest of the naming) 4. During installation (from Catalog) a 'Grafoscopio' folder is created in documents and documentation is downloaded This is a big no. Please don't do this. Not only it violates the isolation of images, but it actually breaks the installation itself when you install Grafoscopio in two different images. If you have to download the docs and you cannot just store them inside the image (which would be logical choice for read-only), then please use the image's directory by default, and only in e.g. development mode use some other location. 5. Node-related bugs Imho this is somehow related to improper use and updates of tree. I remember I had similar issues some time ago, so maybe I can take a look at this in couple of weeks. These bugs sometimes autoresolve themselves (so sometimes it is usable and sometimes not) * 1. Launch > new notebook * 2. Add node > error * 1. Launch > new notebook * 2. Select Node 1 * 3. Add node * 4. Select newNode * 5. rename node to something else * 6. Click on previous "Node 1" > error To summarize: Most are just minor things or annoyances, but #4 is breaking --- as I have to remember to delete the folder every time I want to download Grafoscopio in new image. (If it works for you, then maybe it's platform related (I tested this on Windows 10); in either case, the data related to the image should stay with the image (either in the image, or in the image's folder), and not somewhere in the system). Thanks! Peter

Jan. 19, 2017

Re: [Pharo-users] singleton trait

by Siemen Baader

On Thu, Jan 19, 2017 at 3:51 PM, Siemen Baader <siemenbaader(a)gmail.com> wrote: > > On Thu, Jan 19, 2017 at 11:33 AM, Cyril Ferlicot D. < > cyril.ferlicot(a)gmail.com> wrote: > >> >> You just need a class variable #UniqueInstance and those methods: >> >> current >> "Can also be named #default or #instance" >> ^ UniqueInstance >> ifNil: [ UniqueInstance := self basicNew; initialize; >> yourself ] >> > Actually this should have been: (no `;` between basicNew and initialize). ^ currentInstance ifNil: [ currentInstance := self basicNew initialize; yourself ] This is not a problem. But it illustrates that this would be nice to have it unit tested separately and mixed in with a trait/mixin to avoid the risk of manual errors in what in the end is an already solved problem - if one wants singletons, of course. :) Siemen > > Wouldn't a class instance variable be better? I want new singletons for > every subclass. http://rmod-pharo-mooc.lille.inria.fr/MOOC/Slides/Week3/ > C019-W3S03-Basic-Variables.pdf > > I would also have used super new, why BasicNew? But my wish to create > subclasses seems to answer that already. > > Thanks for your find-grained example, Cyril! > > Siemen >

Jan. 19, 2017

Re: [Pharo-users] singleton trait

by Cyril Ferlicot D.

On 19/01/2017 15:51, Siemen Baader wrote: > > Wouldn't a class instance variable be better? I want new singletons for > every subclass. > http://rmod-pharo-mooc.lille.inria.fr/MOOC/Slides/Week3/C019-W3S03-Basic-Va… I use a class variable because I try to avoid a maximum the use of the Singleton pattern. Most of the time it is wrongly used and it make things harder to maintain in a long time. So I do not want a whole hierarchy of Singleton :) (For some reasons about why Singletons are evil you can easily find articles on internet. I looked quickly and found this for example: https://blogs.msdn.microsoft.com/scottdensmore/2004/05/25/why-singletons-ar…) > > I would also have used super new, why BasicNew? But my wish to create > subclasses seems to answer that already. > When I do Singletons I change the new method to raise an error but I let the developer use #basicNew in order to not forbid him to create a second class if he knows what he's doing. With that we can test the singleton with another instance that the one the application use. > Thanks for your find-grained example, Cyril! > You're welcome :) > Siemen -- Cyril Ferlicot http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

Jan. 19, 2017

Re: [Pharo-users] singleton trait

by jtuchel＠objektfabrik.de

Am 19.01.17 um 15:51 schrieb Siemen Baader: > > Wouldn't a class instance variable be better? I want new singletons > for every subclass. > http://rmod-pharo-mooc.lille.inria.fr/MOOC/Slides/Week3/C019-W3S03-Basic-Va… > > I would also have used super new, why BasicNew? But my wish to create > subclasses seems to answer that already. > super new might cause problems if you also want singletons for all subclasses and at least some of their subclasses and subclasses (1st generation) throw an exception in their #new.

Jan. 19, 2017