Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > pt.comp.programacao > #114 > unrolled thread

Ada-Europe conference - 31 Jan Journal Track Extended Deadline

Back to article view | Back to pt.comp.programacao

Contents

  Ada-Europe conference - 31 Jan Journal Track Extended Deadline dirk@orka.cs.kuleuven.be. (Dirk Craeynest) - 2024-01-08 10:44 +0000
    Re: Ada-Europe conference - 31 Jan Journal Track Extended Deadline Patricia Ferreira <pferreira@example.com> - 2024-01-08 13:05 -0300
      Re: Ada-Europe conference - 31 Jan Journal Track Extended Deadline dirk@orka.cs.kuleuven.be. (Dirk Craeynest) - 2024-01-09 09:53 +0000
        Re: Ada-Europe conference - 31 Jan Journal Track Extended Deadline Patricia Ferreira <pferreira@example.com> - 2024-01-09 09:31 -0300
          Re: Ada-Europe conference - 31 Jan Journal Track Extended Deadline Daniel Cerqueira <dan.list@brilhante.top> - 2024-01-10 13:18 +0000
            Re: Ada-Europe conference - 31 Jan Journal Track Extended Deadline Ninguém <usenet@rasparta.org> - 2024-01-10 15:18 +0000
              fiat lux! (Was: Re: Ada-Europe conference - 31 Jan Journal Track Extended Deadline) Patricia Ferreira <pferreira@example.com> - 2024-01-10 16:57 -0300
                Re: fiat lux! Daniel Cerqueira <dan.list@brilhante.top> - 2024-01-11 16:42 +0000
                  Re: fiat lux! Ninguém <usenet@rasparta.org> - 2024-01-11 22:21 +0000
                    Re: fiat lux! Daniel Cerqueira <dan.list@brilhante.top> - 2024-01-12 14:23 +0000
                      Re: fiat lux! "Nuno Silva" <nunojsilva@invalid.invalid> - 2024-01-16 14:05 +0000
                        Re: fiat lux! Patricia Ferreira <pferreira@example.com> - 2024-01-16 11:45 -0300
                    Re: fiat lux! Patricia Ferreira <pferreira@example.com> - 2024-01-12 11:24 -0300
                  Re: fiat lux! Patricia Ferreira <pferreira@example.com> - 2024-01-12 11:02 -0300
            Lisp (was: Re: Ada-Europe conference - 31 Jan Journal Track Extended Deadline) "Nuno Silva" <nunojsilva@invalid.invalid> - 2024-01-10 16:00 +0000
              Re: Lisp Patricia Ferreira <pferreira@example.com> - 2024-01-10 17:00 -0300
                Re: Lisp Daniel Cerqueira <dan.list@brilhante.top> - 2024-01-11 16:30 +0000
            Lisp, um mapa de trajeto (Was: Re: Ada-Europe conference - 31 Jan Journal Track Extended Deadline) Patricia Ferreira <pferreira@example.com> - 2024-01-10 16:37 -0300
              Re: Lisp, um mapa de trajeto Daniel Cerqueira <dan.list@brilhante.top> - 2024-01-11 17:04 +0000
                Re: Lisp, um mapa de trajeto Patricia Ferreira <pferreira@example.com> - 2024-01-12 11:37 -0300
                  Re: Lisp, um mapa de trajeto Daniel Cerqueira <dan.list@brilhante.top> - 2024-01-12 18:22 +0000
                    Re: Lisp, um mapa de trajeto Ninguém <usenet@rasparta.org> - 2024-01-12 18:51 +0000
                      Re: Lisp, um mapa de trajeto Daniel Cerqueira <dan.list@brilhante.top> - 2024-01-12 22:29 +0000
                        Re: Lisp, um mapa de trajeto Patricia Ferreira <pferreira@example.com> - 2024-01-12 20:27 -0300
                          E-mail (was: Re: Lisp, um mapa de trajeto) "Nuno Silva" <nunojsilva@invalid.invalid> - 2024-01-13 10:34 +0000
                          Re: Lisp, um mapa de trajeto Daniel Cerqueira <dan.list@brilhante.top> - 2024-01-13 13:04 +0000
                            Re: Lisp, um mapa de trajeto Patricia Ferreira <pferreira@example.com> - 2024-01-13 17:02 -0300
                              Re: Lisp, um mapa de trajeto Daniel Cerqueira <dan.list@brilhante.top> - 2024-01-14 12:07 +0000
                                Re: Lisp, um mapa de trajeto Patricia Ferreira <pferreira@example.com> - 2024-01-14 10:39 -0300
                                  Re: Lisp, um mapa de trajeto "Nuno Silva" <nunojsilva@invalid.invalid> - 2024-01-14 15:51 +0000
                                    Re: Lisp, um mapa de trajeto Patricia Ferreira <pferreira@example.com> - 2024-01-14 13:27 -0300
                                  Re: Lisp, um mapa de trajeto Daniel Cerqueira <dan.list@brilhante.top> - 2024-01-14 22:21 +0000
                                    Re: Lisp, um mapa de trajeto Patricia Ferreira <pferreira@example.com> - 2024-01-15 00:24 -0300
                                      Re: Lisp, um mapa de trajeto Daniel Cerqueira <dan.list@brilhante.top> - 2024-01-15 15:23 +0000
                            Re: Lisp, um mapa de trajeto Ninguém <usenet@rasparta.org> - 2024-01-14 10:33 +0000
                    Re: Lisp, um mapa de trajeto Patricia Ferreira <pferreira@example.com> - 2024-01-12 17:01 -0300
                      Re: Lisp, um mapa de trajeto Daniel Cerqueira <dan.list@brilhante.top> - 2024-01-12 22:26 +0000
                        Re: Lisp, um mapa de trajeto Patricia Ferreira <pferreira@example.com> - 2024-01-12 20:50 -0300
                          Re: Lisp, um mapa de trajeto "Nuno Silva" <nunojsilva@invalid.invalid> - 2024-01-13 11:04 +0000
                            Re: Lisp, um mapa de trajeto Patricia Ferreira <pferreira@example.com> - 2024-01-13 09:46 -0300
                          Re: Lisp, um mapa de trajeto Daniel Cerqueira <dan.list@brilhante.top> - 2024-01-13 13:32 +0000
                            Re: Lisp, um mapa de trajeto Patricia Ferreira <pferreira@example.com> - 2024-01-13 16:59 -0300
                              Re: Lisp, um mapa de trajeto Ninguém <usenet@rasparta.org> - 2024-01-14 10:11 +0000
                                Re: Lisp, um mapa de trajeto Patricia Ferreira <pferreira@example.com> - 2024-01-14 11:01 -0300
                                  Re: Lisp, um mapa de trajeto Ninguém <usenet@rasparta.org> - 2024-01-14 14:18 +0000
                                    Re: Lisp, um mapa de trajeto Patricia Ferreira <pferreira@example.com> - 2024-01-14 11:33 -0300
                              Re: Lisp, um mapa de trajeto Daniel Cerqueira <dan.list@brilhante.top> - 2024-01-14 12:02 +0000
                                Re: Lisp, um mapa de trajeto Patricia Ferreira <pferreira@example.com> - 2024-01-14 10:51 -0300
                                  Encriptação (was: Re: Lisp, um mapa de trajeto) "Nuno Silva" <nunojsilva@invalid.invalid> - 2024-01-14 15:44 +0000
                                    Re: Encriptação Patricia Ferreira <pferreira@example.com> - 2024-01-14 13:30 -0300
                                  Re: Lisp, um mapa de trajeto Daniel Cerqueira <dan.list@brilhante.top> - 2024-01-14 22:25 +0000
                                    Re: Lisp, um mapa de trajeto Patricia Ferreira <pferreira@example.com> - 2024-01-15 00:25 -0300
                                      Re: Lisp, um mapa de trajeto Daniel Cerqueira <dan.list@brilhante.top> - 2024-01-15 15:43 +0000
                                        Re: Lisp, um mapa de trajeto Patricia Ferreira <pferreira@example.com> - 2024-01-15 14:00 -0300
                                          Re: Lisp, um mapa de trajeto Daniel Cerqueira <dan.list@brilhante.top> - 2024-01-16 18:10 +0000
                                            Re: Lisp, um mapa de trajeto Patricia Ferreira <pferreira@example.com> - 2024-01-16 22:06 -0300
                                              Re: Lisp, um mapa de trajeto Daniel Cerqueira <dan.list@brilhante.top> - 2024-01-17 14:10 +0000
                                                Re: Lisp, um mapa de trajeto Patricia Ferreira <pferreira@example.com> - 2024-01-18 08:29 -0300
                                                  Re: Lisp, um mapa de trajeto Daniel Cerqueira <dan.list@brilhante.top> - 2024-01-18 18:03 +0000
                                                    Re: Lisp, um mapa de trajeto Patricia Ferreira <pferreira@example.com> - 2024-01-18 15:47 -0300
                                              Re: Lisp, um mapa de trajeto Daniel Cerqueira <dan.list@brilhante.top> - 2024-01-17 15:51 +0000
                                                Re: Lisp, um mapa de trajeto Patricia Ferreira <pferreira@example.com> - 2024-01-18 08:29 -0300
                                                  Re: Lisp, um mapa de trajeto Daniel Cerqueira <dan.list@brilhante.top> - 2024-01-18 17:57 +0000
                                                    Re: Lisp, um mapa de trajeto Patricia Ferreira <pferreira@example.com> - 2024-01-18 15:09 -0300
                                                      Re: Lisp, um mapa de trajeto Daniel Cerqueira <dan.list@brilhante.top> - 2024-01-18 19:24 +0000
                                                        Re: Lisp, um mapa de trajeto Patricia Ferreira <pferreira@example.com> - 2024-01-18 17:56 -0300
                                                          Re: Lisp, um mapa de trajeto Daniel Cerqueira <dan.list@brilhante.top> - 2024-01-19 10:39 +0000
                                                            Re: Lisp, um mapa de trajeto Patricia Ferreira <pferreira@example.com> - 2024-01-19 08:38 -0300
                                                          Re: Lisp, um mapa de trajeto Daniel Cerqueira <dan.list@brilhante.top> - 2024-01-20 13:38 +0000
                                                            Re: Lisp, um mapa de trajeto Patricia Ferreira <pferreira@example.com> - 2024-01-20 11:42 -0300
                                                              Re: Lisp, um mapa de trajeto Daniel Cerqueira <dan.list@brilhante.top> - 2024-01-23 17:29 +0000
                                                                Re: Lisp, um mapa de trajeto Daniel Cerqueira <dan.list@brilhante.top> - 2024-02-03 11:19 +0000
                                                                  Re: Lisp, um mapa de trajeto Patricia Ferreira <pferreira@example.com> - 2024-02-03 09:29 -0300
                                                                    Re: Lisp, um mapa de trajeto Daniel Cerqueira <dan.list@brilhante.top> - 2024-02-03 13:14 +0000
                                                                    Re: Lisp, um mapa de trajeto Daniel Cerqueira <dan.list@brilhante.top> - 2024-02-05 15:43 +0000
                                                                      Re: Lisp, um mapa de trajeto Patricia Ferreira <pferreira@example.com> - 2024-02-05 18:50 -0300
                                                                        Re: Lisp, um mapa de trajeto Daniel Cerqueira <dan.list@brilhante.top> - 2024-02-06 10:55 +0000
                                                                          Re: Lisp, um mapa de trajeto Patricia Ferreira <pferreira@example.com> - 2024-02-06 18:13 -0300
                                                                    Re: Lisp, um mapa de trajeto Daniel Cerqueira <dan.list@brilhante.top> - 2024-02-06 11:11 +0000
                                                                Re: Lisp, um mapa de trajeto Patricia Ferreira <pferreira@example.com> - 2024-02-03 14:52 -0300
                                                                  Re: Lisp, um mapa de trajeto Daniel Cerqueira <dan.list@brilhante.top> - 2024-02-03 18:09 +0000
                                                                    Re: Lisp, um mapa de trajeto Patricia Ferreira <pferreira@example.com> - 2024-02-03 20:48 -0300
                                                                      Re: Lisp, um mapa de trajeto Daniel Cerqueira <dan.list@brilhante.top> - 2024-02-04 11:42 +0000

Page 1 of 5  [1] 2 3 4 5  Next page →

#114 — Ada-Europe conference - 31 Jan Journal Track Extended Deadline

-----------------------------------------------------------------------

                     UPDATED Call for Contributions

              28th Ada-Europe International Conference on
               Reliable Software Technologies (AEiC 2024)

                   11-14 June 2024, Barcelona, Spain

                   www.ada-europe.org/conference2024

       *** Journal track deadline EXTENDED to 31 January 2024 ***
             *** Other submissions by 26 February 2024 ***

                        Organized by Ada-Europe
               and Barcelona Supercomputing Center (BSC),
        in cooperation with ACM SIGAda, ACM SIGBED, ACM SIGPLAN,
                   and Ada Resource Association (ARA)

                  #AEiC2024 #AdaEurope #AdaProgramming

-----------------------------------------------------------------------

*** General Information

The 28th Ada-Europe International Conference on Reliable Software
Technologies (AEiC 2024) will take place in Barcelona, Spain.

AEiC is a leading international forum for providers, practitioners,
and researchers in reliable software technologies.  The conference
presentations will illustrate current work in the theory and practice
of the design, development, and maintenance of long-lived, high-quality
software systems for a challenging variety of application domains.
The program will also include keynotes, Q&A and discussion sessions,
and social events.  Participants include practitioners and researchers
from industry, academia, and government organizations active in the
development of reliable software technologies.

The topics of interest for the conference include but are not limited
to (more specific topics are described on the conference web page):
* Formal and Model-Based Engineering of Critical Systems;
* High-Integrity Systems and Reliability;
* AI for High-Integrity Systems Engineering;
* Real-Time Systems;
* Ada Language;
* Applications in Relevant Domains.

The conference comprises different tracks and co-located events:
* Journal track papers present research advances supported by solid
  theoretical foundation and thorough evaluation.
* Industrial track contributions highlight industrial open challenges
  and/or the practitioners' side of a relevant case study or industrial
  project.
* Work-in-progress track papers illustrate novel research ideas
  that are still at an initial stage, between conception and first
  prototype.
* Tutorials guide attenders through a hands-on familiarization with
  innovative developments or with useful features related to reliable
  software.
* Workshops provide discussion forums on themes related to the
  conference topics.
* Vendor presentations and exhibitions allow for companies to showcase
  their latest products and services.

*** Important Dates

31 January 2024  EXTENDED submission deadline for journal track papers
26 February 2024 Deadline for submission of industrial track papers,
                 work-in-progress papers, tutorial and workshop
                 proposals
22 March 2024    First round notification for journal track papers,
                 and notification of acceptance for all other types
                 of submissions
11-14 June 2024  Conference

*** Call for Journal Track Submissions

Following a journal-first model, this edition of the conference
includes a journal track, which seeks original and high-quality
papers that describe mature research work on the conference topics.
Accepted journal track papers will be published in a Special Issue
of Elsevier JSA - the Journal of Systems Architecture (Q1 ranked,
CiteScore 8.5, impact factor 4.5).  Accordingly, the conference
is listed as "Journal Published" in the latest update of the CORE
Conference Ranking released in August 2023.  Contributions must be
submitted by 31 January 2024.  Submissions should be made online at
https://www.editorialmanager.com/jsa/, selecting the "Ada-Europe AEiC
2024" option (submission page open from 15 November 2023) as article
type of the paper.  General information for submitting to the JSA
can be found at the Journal of Systems Architecture website.

JSA has adopted the Virtual Special Issue model to speed up the
publication process, where Special Issue papers are published in
regular issues, but marked as SI papers.  Acceptance decisions
are made on a rolling basis.  Therefore, authors are encouraged to
submit papers early, and need not wait until the submission deadline.
Authors who have successfully passed the first round of review will
be invited to present their work at the conference.  The abstract of
the accepted contributions will be included in the conference booklet.

The Ada-Europe organization will waive the Open Access fees for
the first four accepted papers (whose authors do not already enjoy
Open Access agreements).  Subsequent papers will follow JSA regular
publishing track.  Prospective authors may direct all enquiries
regarding this track to the corresponding chairs, Bjorn Andersson
(baandersson@sei.cmu.edu) and Luis Miguel Pinho (lmp@isep.ipp.pt).

*** Call for Industrial Track Submissions

The conference seeks industrial practitioner presentations that deliver
insight on the challenges of developing reliable software.  Especially
welcome kinds of submissions are listed on the conference website.
Given their applied nature, such contributions will be subject to a
dedicated practitioner-peer review process.  Interested authors shall
submit a 1-to-2 pages abstract, by 26 February 2024, via EasyChair
at https://easychair.org/my/conference?conf=aeic2024, selecting the
"Industrial Track".  The format for submission is strictly in PDF,
following the Ada User Journal style.  Templates are available at
http://www.ada-europe.org/auj/guide.

The abstract of the accepted contributions will be included in the
conference booklet.  The corresponding authors will get a presentation
slot in the prime-time technical program of the conference and will
also be invited to expand their contributions into full-fledged
articles for publication in the Ada User Journal, which will form the
proceedings of the industrial track of the Conference.  Prospective
authors may direct all enquiries regarding this track to its chairs
Luciana Provenzano (luciana.provenzano@mdu.se) and Michael Pressler
(Michael.Pressler@de.bosch.com).

*** Call for Work-in-Progress Track Submissions

The work-in-progress track seeks two kinds of submissions: (a) ongoing
research and (b) early-stage ideas.  Ongoing research submissions
are 4-page papers describing research results that are not mature
enough to be submitted to the journal track.  Early-stage ideas are
1-page papers that pitch new research directions that fall within
the scope of the conference.  Both kinds of submissions must be
original and shall undergo anonymous peer review.  Submissions
by recent MSc graduates and PhD students are especially sought.
Authors shall submit their work by 26 February 2024, via EasyChair
at https://easychair.org/my/conference?conf=aeic2024, selecting the
"Work-in-Progress Track".  The format for submission is strictly in
PDF, following the Ada User Journal style.  Templates are available
at http://www.ada-europe.org/auj/guide.

The abstract of the accepted contributions will be included in the
conference booklet.  The corresponding authors will get a presentation
slot in the prime-time technical program of the conference and
will also be offered the opportunity to expand their contributions
into 4-page articles for publication in the Ada User Journal,
which will form the proceedings of the WiP track of the Conference.
Prospective authors may direct all enquiries regarding this track
to the corresponding chairs Alejandro R. Mosteo (amosteo@unizar.es)
and Ruben Martins (rubenm@andrew.cmu.edu).

*** Awards

The organization will offer an honorary award for the best technical
presentation, to be announced in the closing session of the conference.

*** Call for Tutorials

The conference seeks tutorials in the form of educational seminars
on themes falling within the conference scope, with an academic or
practitioner slant, including hands-on or practical elements.  Tutorial
proposals shall include a title, an abstract, a description of the
topic, an outline of the presentation, the proposed duration (half-day
or full-day), the intended level of the contents (introductory,
intermediate, or advanced), and a statement motivating attendance.
Tutorial proposals shall be submitted at any time but no later
than the 26 February 2024 to the respective chair Maria A. Serrano
(maria.serrano@nearbycomputing.com), with subject line: "[AEiC 2024:
tutorial proposal]".  Once submitted, each tutorial proposal will
be evaluated by the conference organizers as soon as possible,
with decisions from January 1st.  The authors of accepted full-day
tutorials will receive a complimentary conference registration, halved
for half-day tutorials.  The Ada User Journal will offer space for
the publication of summaries of the accepted tutorials.

*** Call for Workshops

The conference welcomes satellite workshops centred on themes that fall
within the conference scope.  Proposals may be submitted for half- or
full-day events, to be scheduled at either end of the AEiC conference.
Workshop organizers shall also commit to producing the proceedings of
the event, for publication in the Ada User Journal.  Workshop proposals
shall be submitted at any time but no later than the 26 February
2024 to the respective chair Sergio Saez (ssaez@disca.upv.es), with
subject line: "[AEiC 2024: workshop proposal]".  Once submitted, each
workshop proposal will be evaluated by the conference organizers as
soon as possible, with decisions from January 1st.

*** Academic Listing

The Journal of Systems Architecture, publication venue of the journal
track proceedings of the conference, is Q1 ranked, with CiteScore
8.5 and Impact Factor 4.5.  The Ada User Journal, venue of all other
technical proceedings of the conference, is indexed by Scopus and by
EBSCOhost in the Academic Search Ultimate database.

*** Call for Exhibitors and Sponsors

The conference will include a vendor and technology exhibition with the
option of a 20 minutes presentation as part of the conference program.
Interested providers should direct inquiries to the Exhibition &
Sponsorship Chair Ahlan Marriot (ahlan@ada-switzerland.ch).

*** Venue

The conference will take place in Barcelona, Spain.  Barcelona is
a major cultural, economic, and financial centre, known for its
architecture, culture, and Mediterranean atmosphere, a hub for
technology and innovation.  There's plenty to see and visit in
Barcelona, so plan in advance!

*** Organizing Committee

- Conference Chair
  Sara Royuela, Barcelona Supercomputing Center, Spain
  sara.royuela@bsc.es

- Journal Track Chairs
  Bjorn Andersson, Carnegie Mellon University, USA
  baandersson@sei.cmu.edu
  Luis Miguel Pinho, ISEP & INESC TEC, Portugal
  lmp@isep.ipp.pt

- Industrial Track Chairs
  Luciana Provenzano, Mälardalen University, Sweden
  luciana.provenzano@mdu.se
  Michael Pressler, Robert Bosch GmbH, Germany
  Michael.Pressler@de.bosch.com

- Work-In-Progress Track Chairs
  Alejandro R. Mosteo, CUD Zaragoza, Spain
  amosteo@unizar.es
  Ruben Martins, Carnegie Mellon University, USA
  rubenm@andrew.cmu.edu

- Tutorial Chair
  Maria A. Serrano, NearbyComputing, Spain
  maria.serrano@nearbycomputing.com

- Workshop Chair
  Sergio Saez, Universitat Politècnica de València, Spain
  ssaez@disca.upv.es

- Exhibition & Sponsorship Chair
  Ahlan Marriott, White Elephant GmbH, Switzerland
  ahlan@Ada-Switzerland.ch

- Publicity Chair
  Dirk Craeynest, Ada-Belgium & KU Leuven, Belgium
  Dirk.Craeynest@cs.kuleuven.be

- Webmaster
  Hai Nam Tran, University of Brest, France
  hai-nam.tran@univ-brest.fr

- Local Chair
  Nuria Sirvent, Barcelona Supercomputing Center, Spain
  nuria.sirvent@bsc.es

*** Journal Track Committee

Al Mok, University of Texas at Austin, USA
Alejandro Mosteo, CUD Zaragoza, Spain
Alwyn Godloe, NASA, USA
António Casimiro, University of Lisbon, Portugal
Barbara Gallina, Mälardalen University, Sweden
Bernd Burgstaller, Yonsei University, South Korea
C. Michael Holloway, NASA, USA
Cristina Seceleanu, Mälardalen University, Sweden
Doug Schmidt, Vanderbilt University, USA
Frank Singhoff, University of Brest, FR
George Lima, Universidade Federal da Bahia, Brazil
Isaac Amundson, Rockwell Collins, USA
Jérôme Hugues, CMU/SEI, USA
José Cruz, Lockeed Martin, USA
Kristoffer Nyborg Gregertsen, SINTEF Digital, Norway
Laurent Pautet, Telecom ParisTech, France
Leonidas Kosmidis, Barcelona Supercomputing Center, Spain
Mario Aldea Rivas, University of Cantabria, Spain
Matthias Becker, KTH - Royal Institute of Technology, Sweden
Patricia López Martínez, University of Cantabria, Spain
Sara Royuela, Barcelona Supercomputing Center, Spain
Sergio Sáez, Universitat Politècnica de València, Spain
Tucker Taft, AdaCore, USA
Tullio Vardanega, University of Padua, Italy
Xiaotian Dai, University of York, England

*** Industrial Track Committee

Aida Causevic, Alstom, Sweden
Alexander Viehl, Research Center for Information Technology, Germany
Ana Rodríguez, Silver Atena, Spain
Aurora Agar, NATO, Netherlands
Behnaz Pourmohseni, Robert Bosch GmbH, Germany
Claire Dross, AdaCore, France
Elena Lisova, Volvo CE, Sweden
Enricco Mezzeti, Barcelona Supercomputing Center, Spain
Federico Aromolo, Scuola Superiore Sant'Anna, Italy
Helder Silva, Edisoft, Portugal
Hugo Torres Vieira, Evidence Srl, Italy
Irune Agirre, Ikerlan, Spain
Jordi Cardona, Rapita Systems, Spain
José Ruiz, AdaCore, France
Joyce Tokar, Raytheon, USA
Luciana Alvite, Alstom, Germany
Marco Panunzio, Thales Alenia Space, France
Patricia Balbastre Betoret, Valencia Polytechnic University, Spain
Philippe Waroquiers, Eurocontrol NMD, Belgium
Raúl de la Cruz, Collins Aerospace, Ireland
Santiago Urueña, GMV, Spain
Stef Van Vlierberghe, Eurocontrol NMD, Belgium

*** Work-in-Progress Track Committee

Alan Oliveira, University of Lisbon, Portugal
J. Javier Gutiérrez, University of Cantabria, Spain
Jérémie Guiochet, LAAS-CNRS, France
Kalinka Branco, University of São Paulo, Brazil
Katherine Kosaian, University of Iowa, USA
Kevin Cheang, AWS, USA
Kristin Yvonne Rozier, Iowa State University, USA
Leandro Buss Becker, University of Manchester, UK
Li-Pin Chang, National Yang Ming Chiao Tung University, Taiwan
Mathias Preiner, Stanford University, USA
Raffaele Romagnoli, Carnegie Mellon University, USA
Robert Kaiser, RheinMain University of Applied Sciences, Germany
Sara Abbaspour, Mälardalen University, Sweden
Sergi Alcaide, Barcelona Supercomputing Center, Spain
Simona Bernardi, Unizar, Spain
Stefan Mitsch, School of Computing at DePaul University, USA
Teresa Lázaro, Aragon's Institute of Technology, Spain
Tiago Carvalho, ISEP, Portugal
Yannick Moy, AdaCore, France

*** Previous Editions

Ada-Europe organizes annual international conferences since the early
80's.  This is the 28th event in the Reliable Software Technologies
series, previous ones being held at Montreux, Switzerland ('96),
London, UK ('97), Uppsala, Sweden ('98), Santander, Spain ('99),
Potsdam, Germany ('00), Leuven, Belgium ('01), Vienna, Austria
('02), Toulouse, France ('03), Palma de Mallorca, Spain ('04), York,
UK ('05), Porto, Portugal ('06), Geneva, Switzerland ('07), Venice,
Italy ('08), Brest, France ('09), Valencia, Spain ('10), Edinburgh, UK
('11), Stockholm, Sweden ('12), Berlin, Germany ('13), Paris, France
('14), Madrid, Spain ('15), Pisa, Italy ('16), Vienna, Austria ('17),
Lisbon, Portugal ('18), Warsaw, Poland ('19), online from Santander,
Spain ('21), Ghent, Belgium ('22), and Lisbon, Portugal ('23).

Information on previous editions of the conference can be found at
www.ada-europe.org/confs/ae.

-----------------------------------------------------------------------

Our apologies if you receive multiple copies of this announcement.
Please circulate widely.

Dirk Craeynest, AEiC 2024 Publicity Chair
Dirk.Craeynest@cs.kuleuven.be

* 28th Ada-Europe Int. Conf. Reliable Software Technologies (AEiC 2024)
* June 11-14, 2024, Barcelona, Spain, www.ada-europe.org/conference2024

(V4.4)

[toc] | [next] | [standalone]

#115

dirk@orka.cs.kuleuven.be. (Dirk Craeynest) writes:

> *** General Information
>
> The 28th Ada-Europe International Conference on Reliable Software
> Technologies (AEiC 2024) will take place in Barcelona, Spain.
>
> AEiC is a leading international forum for providers, practitioners,
> and researchers in reliable software technologies.  The conference
> presentations will illustrate current work in the theory and practice
> of the design, development, and maintenance of long-lived, high-quality
> software systems for a challenging variety of application domains.

/Long-lived high-quality software systems/.  É interessante que existam
conferências inteiras especializadas numa linguagem de programação só.
/Long-lived high-quality software systems/ em Ada.

Também é legal ver como muitos sistemas de alta qualidade não são
escritos nas linguagens mais populares que existem por aí.

[toc] | [prev] | [next] | [standalone]

#116

>dirk@orka.cs.kuleuven.be. (Dirk Craeynest) writes:
>> AEiC is a leading international forum for providers, practitioners,
>> and researchers in reliable software technologies.  The conference
>> presentations will illustrate current work in the theory and practice
>> of the design, development, and maintenance of long-lived, high-quality
>> software systems for a challenging variety of application domains.

Patricia Ferreira  <pferreira@example.com> wrote:
= /Long-lived high-quality software systems/.  É interessante que
= existam conferências inteiras especializadas numa linguagem de
= programação só.  /Long-lived high-quality software systems/ em Ada.

[Desculpe por não responder em português.]

Note that, while the Ada programming language and technology is an
important topic at the Ada-Europe conference series on *reliable
software technologies*, it is not the only topic (see Call for
Contributions).

= Também é legal ver como muitos sistemas de alta qualidade não são
= escritos nas linguagens mais populares que existem por aí.

Ada might not be the most popular language out there, but definitely
is a very suitable one to develop long-lived high-quality software
systems.  Been there, done that... ;-)

Dirk

[toc] | [prev] | [next] | [standalone]

#117

dirk@orka.cs.kuleuven.be. (Dirk Craeynest) writes:

>>dirk@orka.cs.kuleuven.be. (Dirk Craeynest) writes:
>>> AEiC is a leading international forum for providers, practitioners,
>>> and researchers in reliable software technologies.  The conference
>>> presentations will illustrate current work in the theory and practice
>>> of the design, development, and maintenance of long-lived, high-quality
>>> software systems for a challenging variety of application domains.
>
> Patricia Ferreira  <pferreira@example.com> wrote:
> = /Long-lived high-quality software systems/.  É interessante que
> = existam conferências inteiras especializadas numa linguagem de
> = programação só.  /Long-lived high-quality software systems/ em Ada.
>
> [Desculpe por não responder em português.]

That's alright.  (I bet most of us speak English too.)

> Note that, while the Ada programming language and technology is an
> important topic at the Ada-Europe conference series on *reliable
> software technologies*, it is not the only topic (see Call for
> Contributions).

Because Ada is in the name of conference, I assume it's always Ada we're
talking about that when I read the paragraph below.  (So, thanks for
clarifying.)

--8<---------------cut here---------------start------------->8---
AEiC is a leading international forum for providers, practitioners,
and researchers in reliable software technologies.  The conference
presentations will illustrate current work in the theory and practice
of the design, development, and maintenance of long-lived, high-quality
software systems for a challenging variety of application domains.
The program will also include keynotes, Q&A and discussion sessions,
and social events.  Participants include practitioners and researchers
from industry, academia, and government organizations active in the
development of reliable software technologies.
--8<---------------cut here---------------end--------------->8---

> = Também é legal ver como muitos sistemas de alta qualidade não são
> = escritos nas linguagens mais populares que existem por aí.
>
> Ada might not be the most popular language out there, but definitely
> is a very suitable one to develop long-lived high-quality software
> systems.  Been there, done that... ;-)

I applaude that!  Programming seems to be a field that it's very hard to
educate oneself.  For instance, I never gave myself an introduction to
Ada.  Like most of everyone I assumed it was some relic.  I just visited

  https://ada-lang.io/

for the first time and I was happy to see the website.  

But not all is blues in my life.  Not too late in my life I found Lisp
and I was very surprised to realize how interesting it is and how
ignored it is by the vast percentage of programmers.

I would be so happy to be able to submit a contribution to AEiC, but it
would be much more likely that I would do it for a Lisp conference. :-)

[toc] | [prev] | [next] | [standalone]

#118

Patricia Ferreira <pferreira@example.com> writes:

> But not all is blues in my life.  Not too late in my life I found Lisp
> and I was very surprised to realize how interesting it is and how
> ignored it is by the vast percentage of programmers.
>
> I would be so happy to be able to submit a contribution to AEiC, but it
> would be much more likely that I would do it for a Lisp conference. :-)

Também descobri Lisp tarde, na minha vida professional de programador,
e, bem.... parece que o meu cérebro foi libertado da dor que é o C. Só
tenho prazer a programar em Lisp.

Estou a ler um livro que pensei que tinha perdido (longa história) que é
o Practical Common Lisp. Eu sei que há a versão online, mas após ter
comprado no formato físico, e o ter (pensado ter) perdido, deixei de dar
a continuidade da leitura com o online. Agora voltei, pois encontrei de
novo o livro :-)

Patrícia, quais livros de Lisp leste, e quais recomendas? Que tipo de
Lisp fala esses livros?

Sente-te à vontade de começar uma nova conversa neste grupo. Talvez isto
seja melhor.

[toc] | [prev] | [next] | [standalone]

#119

On 10/01/24 13:18, Daniel Cerqueira wrote:
> Patrícia, quais livros de Lisp leste, e quais recomendas? Que tipo de
> Lisp fala esses livros?

Também estou interessado.
Tento usar emacs, mas sem ser programador e não pescando nada de lisp, 
fica difícil. Limito-me a aproveitar algumas funções mais fáceis de 
entender - é como usar uma bazuca para matar moscas.

[toc] | [prev] | [next] | [standalone]

#122 — fiat lux! (Was: Re: Ada-Europe conference - 31 Jan Journal Track Extended Deadline)

Ninguém <usenet@rasparta.org> writes:

> On 10/01/24 13:18, Daniel Cerqueira wrote:
>> Patrícia, quais livros de Lisp leste, e quais recomendas? Que tipo de
>> Lisp fala esses livros?
>
> Também estou interessado.
> Tento usar emacs, mas sem ser programador e não pescando nada de lisp,
> fica difícil. Limito-me a aproveitar algumas funções mais fáceis de 
> entender - é como usar uma bazuca para matar moscas.

O GNU EMACS é um software difícil de usar.  Pra valer a pena o uso dele,
a gente faz um monte de customizações ao longo dos anos.  O próprio uso
do GNU EMACS nos convida a conhecer Lisp e a vida no GNU EMACS sem Lisp
certamente não é a mais fácil.  Por outro lado... O que mais tem por aí?
Tenho certeza que VSCode oferece um ambiente Lisp, mas não sei usar
aquilo e nem quero saber --- o GNU EMACS funciona muito bem pra quem
investiu bastante no uso dele.

Racket é uma escola completa.  O DrRacket é fácil de instalar e usar.
Sem mistério.  O HtDP é um livro pra iniciantes com profundas mensagens
e assume que você usará o DrRacket.  

O SICP não é um livro que deve ser lido sem o leitor dominar as ideias
centrais do HtDP, por exemplo.

Agora, observe que em mensagem anterior eu disse que ter começado com
Racket foi minha pior decisão.  Entender Racket não me parece fácil.
Tudo com Racket vai muito bem enquanto você está lendo o HtDP.  O
problema é quando você resolve usar a linguagem de fato mesmo.  Aí você
precisa ler a documentação, entender as coisas.  É um outro mundo
completo a desbravar.  Teria me dado muito melhor com Common Lisp.
Finalmente descobri isso.

[toc] | [prev] | [next] | [standalone]

#125 — Re: fiat lux!

Patricia Ferreira <pferreira@example.com> writes:

> Ninguém <usenet@rasparta.org> writes:
>
>> On 10/01/24 13:18, Daniel Cerqueira wrote:
>>> Patrícia, quais livros de Lisp leste, e quais recomendas? Que tipo de
>>> Lisp fala esses livros?
>>
>> Também estou interessado.
>> Tento usar emacs, mas sem ser programador e não pescando nada de lisp,
>> fica difícil. Limito-me a aproveitar algumas funções mais fáceis de 
>> entender - é como usar uma bazuca para matar moscas.
>
> O GNU EMACS é um software difícil de usar.  Pra valer a pena o uso dele,
> a gente faz um monte de customizações ao longo dos anos.  O próprio uso
> do GNU EMACS nos convida a conhecer Lisp e a vida no GNU EMACS sem Lisp
> certamente não é a mais fácil.  Por outro lado... O que mais tem por aí?
> Tenho certeza que VSCode oferece um ambiente Lisp, mas não sei usar
> aquilo e nem quero saber --- o GNU EMACS funciona muito bem pra quem
> investiu bastante no uso dele.

Acho que chamar o GNU Emacs de difícil é uma má descrição.
Eu vejo desta maneira: Dá para expandir bastante o conhecimento do GNU
Emacs. Também dá para usá-lo de maneira simples.

O melhor a fazer é pegar numa configuração de Emacs (um .emacs ou
init.el) que anda nos resultados do teu motor de busca web favorito, e
aproveitar o que precisas. A partir de aí, vais construindo as tuas
configurações do GNU Emacs, com o passar dos dias, meses, anos.

Eu comecei a usar Emacs sem saber algo de Lisp, e consegui.

As minhas configurações de Emacs estão aqui:
https://danisanti.tilde.institute/files/emacs

[toc] | [prev] | [next] | [standalone]

#127 — Re: fiat lux!

Daniel Cerqueira (dan.list@brilhante.top) escreveu no dia 2024-01-11
(Thursday), cerca das 16:42 +0000:
> Acho que chamar o GNU Emacs de difícil é uma má descrição.
> Eu vejo desta maneira: Dá para expandir bastante o conhecimento do
> GNU
> Emacs. Também dá para usá-lo de maneira simples.

Hehe!
Uso de maneira simples, então.

> O melhor a fazer é pegar numa configuração de Emacs (um .emacs ou
> init.el) que anda nos resultados do teu motor de busca web favorito,
> e
> aproveitar o que precisas. A partir de aí, vais construindo as tuas
> configurações do GNU Emacs, com o passar dos dias, meses, anos.

Eu entendo essa filosofia até certo ponto. Faço isso com o bash porque
já tenho algum conhecimento de bash, mas tenho dificuldade em utilizar
essa metodologia quando não entendo o que estou a fazer. Sinto-me um
bocado feiticeiro de Oz.
Não entendendo lisp, por exemplo, colocar uma data de "tralha que não
sei o que faz só porque tem o efeito que eu pretendo" no ficheiro de
configuração pode resolver-me o problema de utilização, mas não o de
ignorância.
Acho que a metodologia que a Patrícia sempre sugere talvez seja melhor
- ler um bom livro sobre o assunto - pelo menos até entender o mínimo
para ser perigoso, depois então, ok, ir arriscando um bocadinho.
Há pouco tempo dei com um artigo com o título semelhante a "emacs from
scratch". Pareceu-me adequado ao que pretendo, mas começa logo por me
pedir para confiar nas "magias" que o autor sugere à partida!...
desiludiu-me um bocado.

> Eu comecei a usar Emacs sem saber algo de Lisp, e consegui.
> 
> As minhas configurações de Emacs estão aqui:
> https://danisanti.tilde.institute/files/emacs

"Bookmarkado" ;-)

[toc] | [prev] | [next] | [standalone]

#129 — Re: fiat lux!

Ninguém <usenet@rasparta.org> writes:

> Daniel Cerqueira (dan.list@brilhante.top) escreveu no dia 2024-01-11
> (Thursday), cerca das 16:42 +0000:
>
> Não entendendo lisp, por exemplo, colocar uma data de "tralha que não
> sei o que faz só porque tem o efeito que eu pretendo" no ficheiro de
> configuração pode resolver-me o problema de utilização, mas não o de
> ignorância.
> Acho que a metodologia que a Patrícia sempre sugere talvez seja melhor
> - ler um bom livro sobre o assunto - pelo menos até entender o mínimo
> para ser perigoso, depois então, ok, ir arriscando um bocadinho.

Apoio essa metodologia. Eu também sou assim.

Uma ótima coisa no Emacs, é que podes aprender sobre o Emacs usando o
Emacs. Bootstrapping knowleadge :-) Por exemplo, tens o tutorial do
Emacs dentro do Emacs. Podes aceder ao tutorial usando C-h t (isto é,
Control pressionada mais a tecla h, largar o Control e carregar na tecla
t). Também tens o C-h C-h (isto é, Control pressionado e duas vezes a
tecla h) que é como obténs ajuda sobre a ajuda do Emacs.

> Há pouco tempo dei com um artigo com o título semelhante a "emacs from
> scratch". Pareceu-me adequado ao que pretendo, mas começa logo por me
> pedir para confiar nas "magias" que o autor sugere à partida!...
> desiludiu-me um bocado.

Espero que encontres algo melhor ;-) Se sabes usar o info do GNU, tens
vários livros info sobre Emacs e Emacs Lisp instalados no teu sistema.
Podes aceder ao info dentro do Emacs com C-h i

[toc] | [prev] | [next] | [standalone]

#166 — Re: fiat lux!

On 2024-01-12, Daniel Cerqueira wrote:

> Ninguém <usenet@rasparta.org> writes:
>
>> Daniel Cerqueira (dan.list@brilhante.top) escreveu no dia 2024-01-11
>> (Thursday), cerca das 16:42 +0000:
>>
>> Não entendendo lisp, por exemplo, colocar uma data de "tralha que não
>> sei o que faz só porque tem o efeito que eu pretendo" no ficheiro de
>> configuração pode resolver-me o problema de utilização, mas não o de
>> ignorância.
>> Acho que a metodologia que a Patrícia sempre sugere talvez seja melhor
>> - ler um bom livro sobre o assunto - pelo menos até entender o mínimo
>> para ser perigoso, depois então, ok, ir arriscando um bocadinho.
>
> Apoio essa metodologia. Eu também sou assim.
>
> Uma ótima coisa no Emacs, é que podes aprender sobre o Emacs usando o
> Emacs. Bootstrapping knowleadge :-) Por exemplo, tens o tutorial do
> Emacs dentro do Emacs. Podes aceder ao tutorial usando C-h t (isto é,
> Control pressionada mais a tecla h, largar o Control e carregar na tecla
> t). Também tens o C-h C-h (isto é, Control pressionado e duas vezes a
> tecla h) que é como obténs ajuda sobre a ajuda do Emacs.

A ajuda interactiva do Emacs é capaz de ser dos melhores sistemas de
ajuda que já conheci até ao momento.

Recomendo F1 f e F1 v para ver a documentação de funções e variávis (e
a prompt para escrever o nome da função/variável permite não só
completar o resto do nome e ver o que existe com o prefixo introduzido,
mas também preencher segmentos intermédios (em vez de só no fim do que
foi escrito), o que ajuda a descobrir mais algumas coisas).

Escrevendo algo como "inicio--fim", e fazendo de seguida C-i/tab, o
minibuffer vai encontrar inicio-a-fim e inicio-b-fim-c, por exemplo
(assumindo que essas funções ou variáveis existem, claro). Isto pode
ser uma forma interessante de descobrir funções e variáveis.

(Talvez isto dependa da versão do GNU Emacs? Tenho observado este
comportamento há bastante tempo, mas sem ir investigar não sei há
quanto tempo é assim.)

(F1 ou C-h deverá ir dar ao mesmo em muitos casos, eu é que aqui do
meu lado evito o C-h porque a inicialização para o terminal faz com
que C-h deixe de funcionar pelo menos nalguns casos, e uso sempre F1
para evitar surpresas.)


-- 
Nuno Silva

[toc] | [prev] | [next] | [standalone]

#167 — Re: fiat lux!

"Nuno Silva" <nunojsilva@invalid.invalid> writes:

[...]

> A ajuda interactiva do Emacs é capaz de ser dos melhores sistemas de
> ajuda que já conheci até ao momento.
>
> Recomendo F1 f e F1 v para ver a documentação de funções e variávis (e
> a prompt para escrever o nome da função/variável permite não só
> completar o resto do nome e ver o que existe com o prefixo introduzido,
> mas também preencher segmentos intermédios (em vez de só no fim do que
> foi escrito), o que ajuda a descobrir mais algumas coisas).
>
> Escrevendo algo como "inicio--fim", e fazendo de seguida C-i/tab, o
> minibuffer vai encontrar inicio-a-fim e inicio-b-fim-c, por exemplo
> (assumindo que essas funções ou variáveis existem, claro). Isto pode
> ser uma forma interessante de descobrir funções e variáveis.
>
> (Talvez isto dependa da versão do GNU Emacs? Tenho observado este
> comportamento há bastante tempo, mas sem ir investigar não sei há
> quanto tempo é assim.)

É o padrão, assim como C-h.

[toc] | [prev] | [next] | [standalone]

#130 — Re: fiat lux!

Ninguém <usenet@rasparta.org> writes:

> Daniel Cerqueira (dan.list@brilhante.top) escreveu no dia 2024-01-11
> (Thursday), cerca das 16:42 +0000:

[...]

>> O melhor a fazer é pegar numa configuração de Emacs (um .emacs ou
>> init.el) que anda nos resultados do teu motor de busca web favorito,
>> e aproveitar o que precisas. A partir de aí, vais construindo as tuas
>> configurações do GNU Emacs, com o passar dos dias, meses, anos.
>
> Eu entendo essa filosofia até certo ponto. Faço isso com o bash porque
> já tenho algum conhecimento de bash, mas tenho dificuldade em utilizar
> essa metodologia quando não entendo o que estou a fazer. Sinto-me um
> bocado feiticeiro de Oz.
> Não entendendo lisp, por exemplo, colocar uma data de "tralha que não
> sei o que faz só porque tem o efeito que eu pretendo" no ficheiro de
> configuração pode resolver-me o problema de utilização, mas não o de
> ignorância.
> Acho que a metodologia que a Patrícia sempre sugere talvez seja melhor
> - ler um bom livro sobre o assunto - pelo menos até entender o mínimo
> para ser perigoso, depois então, ok, ir arriscando um bocadinho.
> Há pouco tempo dei com um artigo com o título semelhante a "emacs from
> scratch". Pareceu-me adequado ao que pretendo, mas começa logo por me
> pedir para confiar nas "magias" que o autor sugere à partida!...
> desiludiu-me um bocado.

Meu método é esse mesmo --- um livro pra cada ferramenta que uso.  Por
exemplo, o livro do /ls/ você encontra ao dizer

  man ls

a seu shell.  O GNU EMACS tem seus livros em si próprio.  Tem
ferramentas que nos leverão a vários livros.  Por exemplo, uma linguagem
de programação.

Você já deve ter visto por aí programas de uma só linha escritos em AWK.
Você já leu ``The AWK Programming Language''?  Leia-o e compreenda-os.

Cara programa de computador funciona como uma linguagem de programação.
O /ls/ possui uma série de construtores de linguagem, o que você
descobre no livro.  Todo programa-ls tem a forma 

  ls [OPTIONS]... [FILE]...

Estritamente falando, o programa não inclui o /ls/ porque, na verdade,
esse construtor inicial é de uma outra linguagem --- chamada usualmente
de /shell/.  Então um programa-ls tem na verdade a forma

  [OPTIONS]... [FILE]...

Conhecendo um mínimo sobre o shell e lendo o livro /ls/, compreender os
resultados abaixos é tarefa trivial.  Sem ler o livro, é um trabalho
realmente difícil de ser feito.

--8<---------------cut here---------------start------------->8---
%ls -i Makefile*
12666373952139719 Makefile
 4785074604376244 Makefile.~1~
12384898975409143 Makefile.~2~
18014398509613044 Makefile.~3~
--8<---------------cut here---------------end--------------->8---

--8<---------------cut here---------------start------------->8---
%ls -i -r Makefile*
18014398509613044 Makefile.~3~
12384898975409143 Makefile.~2~
 4785074604376244 Makefile.~1~
12666373952139719 Makefile
--8<---------------cut here---------------end--------------->8---

O princípio que emerge aqui então é o princípio de que pra usar uma
ferramenta de computador é preciso estudá-la.  Cada uma.  O que parece
uma tarefa absurda, é na verdade muito sensata.  O processo produz uma
grande economia de tempo.

Um artigo na Internet em média não tem o cuidado que um livro tem.  Uma
pessoa escreve um livro usualmente pensando em fazer uma obra que dure
muitos anos, talvez pra sempre.  Ainda lemos a República de Platão com
grande interesse.  ``The C Programming Language'' de Brian Kernighan e
Dennis Ritchie ainda é provavelmente a melhor apresentação sobre C.  E
mesmo que não fosse, sua importância história nos faz lê-lo.  A gente
não estuda só pra saber usar uma ferramenta; a gente estuda também pra
entender o pensamento médio.  Assuntos técnicos fluem numa comunidade e
é preciso entender a comunidade.  Não se sugere que você leia qualquer
lixo.  Muitos fenômenos técnicos hoje são na verdade propaganda.
Estudar a história do tema usualmente nos permite detectar o fato e
então dispensar o conteúdo comtemporâneo que é só propaganda, perda de
tempo e ilusão.  (Mas aqui a gente entra em outro assunto.)

Com experiência, você não gasta seu tempo com livros que não são
interessantes e nem se envolve com movimentos que não são interessante.

[toc] | [prev] | [next] | [standalone]

#128 — Re: fiat lux!

Daniel Cerqueira <dan.list@brilhante.top> writes:

> Patricia Ferreira <pferreira@example.com> writes:
>
>> Ninguém <usenet@rasparta.org> writes:
>>
>>> On 10/01/24 13:18, Daniel Cerqueira wrote:
>>>> Patrícia, quais livros de Lisp leste, e quais recomendas? Que tipo de
>>>> Lisp fala esses livros?
>>>
>>> Também estou interessado.
>>> Tento usar emacs, mas sem ser programador e não pescando nada de lisp,
>>> fica difícil. Limito-me a aproveitar algumas funções mais fáceis de 
>>> entender - é como usar uma bazuca para matar moscas.
>>
>> O GNU EMACS é um software difícil de usar.  Pra valer a pena o uso dele,
>> a gente faz um monte de customizações ao longo dos anos.  O próprio uso
>> do GNU EMACS nos convida a conhecer Lisp e a vida no GNU EMACS sem Lisp
>> certamente não é a mais fácil.  Por outro lado... O que mais tem por aí?
>> Tenho certeza que VSCode oferece um ambiente Lisp, mas não sei usar
>> aquilo e nem quero saber --- o GNU EMACS funciona muito bem pra quem
>> investiu bastante no uso dele.
>
> Acho que chamar o GNU Emacs de difícil é uma má descrição.
> Eu vejo desta maneira: Dá para expandir bastante o conhecimento do GNU
> Emacs. Também dá para usá-lo de maneira simples.

Meu ponto de vista é a de um usuário mediano.  Se eu o achasse realmente
difícil de usar, não o usaria.  Se você for um programador e
especialmente se for um programador Lisp, o GNU EMACS é maravilhoso ou
quase isso.  Se o uso for simples, talvez não haja no GNU EMACS nada que
realmente valha a pena.

Quando uma coisa é difícil de usar, é interessante entender por quê.  Às
vezes a razão é simplesmente mal-projeto e aí a gente joga aquilo fora.
Tipicamente a gente consegue fazer a distinção por observar outras
pessoas usando.  Se você observar alguns estudiosos do GNU EMACS
usando-o, você vê que o que parecia difícil é na verdade muito fácil
(pra eles).  Então talvez não seja mal-projeto, mas uma ferramenta que
/você/ não compreenda.

De uma forma geral, uma abordagem interessante pra compreender /qualquer
coisa/ é compreender sua história.  O GNU EMACS tem uma longa, longa
história.  O nome EMACS já era usado por outros editores antes do GNU
EMACS.  EMACS deriva-se de ``[e]ditor of [mac]ro[s]''.  Em programação,
``macros'' representa a ideia de procedimentos que um compilador executa
(e não que seu programa executa).  Só isso já sugere que EMACS tinha em
mente programadores LISP, o que sugere por sua vez que compreender LISP
seja útil pra compreender o próprio EMACS e sua história.  Muitos
editores EMACS foram escritos.  (Por exemplo, James Gosling, além de
Java, também escreveu um EMACS, chamado ``gosmacs''.)

Por que o GNU EMACS se minimiza quando se diz C-z?  Porque está próximo
do efeito de se interromper o processo que está em primeiro plano no seu
terminal.  Por que o GNU EMACS não ``se moderniza'' e se comporta como
programas Microsoft Windows?  Primeiro porque o uso da palavra
``moderno'' não está muito adequada ao contexto; segundo porque o GNU
EMACS tem uma história muito mais longa que o Microsoft Windows.  A
resposta curta pra essa pergunta é --- ``thanks, but no, thanks''.  É
claro que o GNU EMACS poderia se comportar exatamente como um programa
Windows, mas não /se deseja isso/.  

E aí começa a compreensão do porquê o GNU EMACS é tão difícil de usar
--- é porque você não tem essa cultura.  Se você gosta do GNU EMACS e
deseja ter a habilidade de usá-lo, você precisa adquirir essa cultura.
Tem essa cultura quem sabe usar o GNU EMACS com eficácia.

Compreender a configuração de um GNU EMACS e compreender a documentação
vai ficar muito mais óbvia se você tiver um mínimo de linguagens Lisp.
Se seu objetivo é mais o GNU EMACS do que qualquer Lisp, então dê a si
mesmo um curso de ELISP.

Só comecei a entender o GNU EMACS depois de ler 

  An Introduction to Programming in Emacs Lisp
  Robert J. Chassell, GNU Press,  ISBN 1-882114-43-4
  
--8<---------------cut here---------------start------------->8---
This is ‘An Introduction to Programming in Emacs Lisp’, for people who
are not programmers.
--8<---------------cut here---------------end--------------->8---

Você encontra o livro no próprio GNU EMACS dizendo

  Help -> More manuals -> Introduction to Emacs Lisp

ao seu GNU EMACS.

[toc] | [prev] | [next] | [standalone]

#120 — Lisp (was: Re: Ada-Europe conference - 31 Jan Journal Track Extended Deadline)

On 2024-01-10, Daniel Cerqueira wrote:

> Patricia Ferreira <pferreira@example.com> writes:
>
>> But not all is blues in my life.  Not too late in my life I found Lisp
>> and I was very surprised to realize how interesting it is and how
>> ignored it is by the vast percentage of programmers.
>>
>> I would be so happy to be able to submit a contribution to AEiC, but it
>> would be much more likely that I would do it for a Lisp conference. :-)
>
> Também descobri Lisp tarde, na minha vida professional de programador,
> e, bem.... parece que o meu cérebro foi libertado da dor que é o C. Só
> tenho prazer a programar em Lisp.
>
> Estou a ler um livro que pensei que tinha perdido (longa história) que é
> o Practical Common Lisp. Eu sei que há a versão online, mas após ter
> comprado no formato físico, e o ter (pensado ter) perdido, deixei de dar
> a continuidade da leitura com o online. Agora voltei, pois encontrei de
> novo o livro :-)
>
> Patrícia, quais livros de Lisp leste, e quais recomendas? Que tipo de
> Lisp fala esses livros?
>
> Sente-te à vontade de começar uma nova conversa neste grupo. Talvez isto
> seja melhor.

Embora já conhecesse C, eu travei conhecimento digamos que "bem cedo"
(isto é, antes de aprender e/ou trabalhar com muitas outras linguagens)
com a família Lisp, neste caso R5RS (portanto Scheme).

Sei que a dada altura li o SICP e penso que o "ANSI Common Lisp" (se não
foi esse, a capa pelo menos parece semelhante, e tenho a certeza de que
incluía um exemplo com ray-tracing).

Penso que terei lido também (parcialmente?) outro livro, que me sugeriram
pouco antes de começar a utilizar R5RS, terá sido o HtDP?

Se algum de vocês anda pelos lados do "fediverso", sugiro esta conta
para alguns posts interessantes sobre Lisp:
http://fosstodon.org/@amoroso

(Com sorte, para receber esses posts bastaria seguir a hashtag #Lisp mas
isso depende da federação, tal como aliás se discutiu recentemente no
pt.internet.www.)

-- 
Nuno Silva

[toc] | [prev] | [next] | [standalone]

#123 — Re: Lisp

"Nuno Silva" <nunojsilva@invalid.invalid> writes:

> On 2024-01-10, Daniel Cerqueira wrote:
>
>> Patricia Ferreira <pferreira@example.com> writes:
>>
>>> But not all is blues in my life.  Not too late in my life I found Lisp
>>> and I was very surprised to realize how interesting it is and how
>>> ignored it is by the vast percentage of programmers.
>>>
>>> I would be so happy to be able to submit a contribution to AEiC, but it
>>> would be much more likely that I would do it for a Lisp conference. :-)
>>
>> Também descobri Lisp tarde, na minha vida professional de programador,
>> e, bem.... parece que o meu cérebro foi libertado da dor que é o C. Só
>> tenho prazer a programar em Lisp.
>>
>> Estou a ler um livro que pensei que tinha perdido (longa história) que é
>> o Practical Common Lisp. Eu sei que há a versão online, mas após ter
>> comprado no formato físico, e o ter (pensado ter) perdido, deixei de dar
>> a continuidade da leitura com o online. Agora voltei, pois encontrei de
>> novo o livro :-)
>>
>> Patrícia, quais livros de Lisp leste, e quais recomendas? Que tipo de
>> Lisp fala esses livros?
>>
>> Sente-te à vontade de começar uma nova conversa neste grupo. Talvez isto
>> seja melhor.
>
> Embora já conhecesse C, eu travei conhecimento digamos que "bem cedo"
> (isto é, antes de aprender e/ou trabalhar com muitas outras linguagens)
> com a família Lisp, neste caso R5RS (portanto Scheme).
>
> Sei que a dada altura li o SICP e penso que o "ANSI Common Lisp" (se não
> foi esse, a capa pelo menos parece semelhante, e tenho a certeza de que
> incluía um exemplo com ray-tracing).

É o ANSI Common Lisp sim.

> Penso que terei lido também (parcialmente?) outro livro, que me sugeriram
> pouco antes de começar a utilizar R5RS, terá sido o HtDP?

Se fosse o HtDP, você lembraria.

> Se algum de vocês anda pelos lados do "fediverso", sugiro esta conta
> para alguns posts interessantes sobre Lisp:
> http://fosstodon.org/@amoroso

O Paolo Amoroso anda pelo comp.lang.lisp atualmente.

[toc] | [prev] | [next] | [standalone]

#124 — Re: Lisp

Patricia Ferreira <pferreira@example.com> writes:

> O Paolo Amoroso anda pelo comp.lang.lisp atualmente.

Sim, tenho visto bastante atividade do Amoroso em comp.lang.lisp ;-)

[toc] | [prev] | [next] | [standalone]

#121 — Lisp, um mapa de trajeto (Was: Re: Ada-Europe conference - 31 Jan Journal Track Extended Deadline)

Daniel Cerqueira <dan.list@brilhante.top> writes:

> Patricia Ferreira <pferreira@example.com> writes:
>
>> But not all is blues in my life.  Not too late in my life I found Lisp
>> and I was very surprised to realize how interesting it is and how
>> ignored it is by the vast percentage of programmers.
>>
>> I would be so happy to be able to submit a contribution to AEiC, but it
>> would be much more likely that I would do it for a Lisp conference. :-)
>
> Também descobri Lisp tarde, na minha vida professional de programador,
> e, bem.... parece que o meu cérebro foi libertado da dor que é o C. Só
> tenho prazer a programar em Lisp.

Que bom!  E que bom que você conhece C também.

> Estou a ler um livro que pensei que tinha perdido (longa história)

Lol.

> que é o Practical Common Lisp. Eu sei que há a versão online, mas após
> ter comprado no formato físico, e o ter (pensado ter) perdido, deixei
> de dar a continuidade da leitura com o online. Agora voltei, pois
> encontrei de novo o livro :-)

Sempre melhor ter o livros em mãos.

> Patrícia, quais livros de Lisp leste, e quais recomendas? Que tipo de
> Lisp fala esses livros?

Os livros de Lisp que realmente li foram o HtDP e o SICP.  Tem muita
coisa a se conversar aí.  O Practical Common Lisp vai te apresentar um
jeito Common Lisp de escrever, mas é preciso saber se você já tem um
pouco do jeito Lisp de pensar --- antes do jeito Common Lisp.  Você tem
sentido alguma dificuldade em algum lugar que você consiga descrever?  A
gente começa a conversa por aí.

Estou iniciando com Common Lisp --- descobri esses dias.  Não sabia que
era tão divertido usar Common Lisp.  São poucos dias ainda, mas a gente
sabe o que gosta quando vê.  É /absolutamente/ a melhor experiência que
já tive.  Uso o GNU EMACS há muitos anos.  Agora estou usando SLIME e
SBCL.  Estou me divertindo *muito mais* com SBCL e SLIME do que com
Racket e racket-mode.  Muito mais.  As mensagens de erro do SBCL são
maravilhosas comparadas às mensagens de erro de Racket.

[toc] | [prev] | [next] | [standalone]

#126 — Re: Lisp, um mapa de trajeto

Patricia Ferreira <pferreira@example.com> writes:

> Que bom!  E que bom que você conhece C também.

Sim, aprendi na Universidade do Minho. Infelizmente zero Lisp no curso
de Engenharia Informática. Apenas Haskell.

>> Estou a ler um livro que pensei que tinha perdido (longa história)
>
> Lol.
>
>> que é o Practical Common Lisp. Eu sei que há a versão online, mas após
>> ter comprado no formato físico, e o ter (pensado ter) perdido, deixei
>> de dar a continuidade da leitura com o online. Agora voltei, pois
>> encontrei de novo o livro :-)
>
> Sempre melhor ter o livros em mãos.
>

Comprei o livro, por estar em preço de promoção, e andava do olho nele
porque achei muito fixe o autor libertar o livro em formato online,
gratuitamente. Mereceu o meu dinheiro escasso.

>> Patrícia, quais livros de Lisp leste, e quais recomendas? Que tipo de
>> Lisp fala esses livros?
>
> Os livros de Lisp que realmente li foram o HtDP e o SICP.  Tem muita
> coisa a se conversar aí.  O Practical Common Lisp vai te apresentar um
> jeito Common Lisp de escrever, mas é preciso saber se você já tem um
> pouco do jeito Lisp de pensar --- antes do jeito Common Lisp.  Você tem
> sentido alguma dificuldade em algum lugar que você consiga descrever?  A
> gente começa a conversa por aí.

A dificuldade que tenho é apenas em decorar as várias funções/macros da
linguagem. Fora isso tenho andado bem, a passo lento, com tempo para
assimilação.

> Estou iniciando com Common Lisp --- descobri esses dias.  Não sabia que
> era tão divertido usar Common Lisp.  São poucos dias ainda, mas a gente
> sabe o que gosta quando vê.  É /absolutamente/ a melhor experiência que
> já tive.  Uso o GNU EMACS há muitos anos.  Agora estou usando SLIME e
> SBCL.  Estou me divertindo *muito mais* com SBCL e SLIME do que com
> Racket e racket-mode.  Muito mais.  As mensagens de erro do SBCL são
> maravilhosas comparadas às mensagens de erro de Racket.

Que bom que também partilhas este prazer. Escrever Common Lisp é
maravilhoso. Principalmente com o GNU Emacs.

Eu não uso SLIME porque não dá para criar imagens lisp com o SLIME. Uso
M-x run-lisp , e assim já consigo usar o save-lisp-and-die. Tenho uma
atitute minimalista com o software, uso apenas aquilo que realmente
preciso, tento não usar dois softwares que fazem a mesma coisa.

Também uso o SBCL.

Patricia, eu li e recomendo ler, os livros do John McCarthy sobre Lisp.

Que personagem. Dá para ver nos livros dele que ele era uma pessoa
brilhante. São simples e fácil de entender. Quem lê, fica a saber a
raíz por onde começou. Que é a melhor maneira de adquirir conhecimento.

Um dos seus websites é: http://www-formal.stanford.edu/jmc/

[toc] | [prev] | [next] | [standalone]

#131 — Re: Lisp, um mapa de trajeto

Daniel Cerqueira <dan.list@brilhante.top> writes:

> Patricia Ferreira <pferreira@example.com> writes:
>
>> Que bom!  E que bom que você conhece C também.
>
> Sim, aprendi na Universidade do Minho. Infelizmente zero Lisp no curso
> de Engenharia Informática. Apenas Haskell.

Ou felizmente.  Talvez você odiasse Lisp.  É o que acontece com
matemática e português, dado que (quase) todas as crianças vão à escola.

>>> Patrícia, quais livros de Lisp leste, e quais recomendas? Que tipo de
>>> Lisp fala esses livros?
>>
>> Os livros de Lisp que realmente li foram o HtDP e o SICP.  Tem muita
>> coisa a se conversar aí.  O Practical Common Lisp vai te apresentar um
>> jeito Common Lisp de escrever, mas é preciso saber se você já tem um
>> pouco do jeito Lisp de pensar --- antes do jeito Common Lisp.  Você tem
>> sentido alguma dificuldade em algum lugar que você consiga descrever?  A
>> gente começa a conversa por aí.
>
> A dificuldade que tenho é apenas em decorar as várias funções/macros da
> linguagem. 

Qual delas?  Common Lisp?

> Fora isso tenho andado bem, a passo lento, com tempo para assimilação.

Vamos começar bem do zero e investigar onde estamos.  (Estou assumindo
Common Lisp.)  Qual seria um bom nome pro procedimento abaixo?  Quanto
tempo você levou pra chegar a sua resposta?

(defun f (ls)
  (cond
    ((null ls) nil)
    ((consp ls)
     (or (string= (car ls) "gluten")
         (f (cdr ls))))))

>> Estou iniciando com Common Lisp --- descobri esses dias.  Não sabia que
>> era tão divertido usar Common Lisp.  São poucos dias ainda, mas a gente
>> sabe o que gosta quando vê.  É /absolutamente/ a melhor experiência que
>> já tive.  Uso o GNU EMACS há muitos anos.  Agora estou usando SLIME e
>> SBCL.  Estou me divertindo *muito mais* com SBCL e SLIME do que com
>> Racket e racket-mode.  Muito mais.  As mensagens de erro do SBCL são
>> maravilhosas comparadas às mensagens de erro de Racket.
>
> Que bom que também partilhas este prazer. Escrever Common Lisp é
> maravilhoso. Principalmente com o GNU Emacs.
>
> Eu não uso SLIME porque não dá para criar imagens lisp com o SLIME. Uso
> M-x run-lisp , e assim já consigo usar o save-lisp-and-die. Tenho uma
> atitute minimalista com o software, uso apenas aquilo que realmente
> preciso, tento não usar dois softwares que fazem a mesma coisa.

Mas assim você não tem uma integração entre seu buffer no GNU EMACS e o
*inferior-lisp*.  Você não vai usar save-lisp-and-die o tempo todo.
Lembre-se de que você pode e deve manter o estado do seu programa num
programa.lisp.  Você consegue reproduzir a imagem de Lisp sempre.  Não
precisa salvá-la por completo assim.

> Patricia, eu li e recomendo ler, os livros do John McCarthy sobre Lisp.

Vamos enumerar esses livros.  Qual o primeiro que você recomenda?

> Que personagem. Dá para ver nos livros dele que ele era uma pessoa
> brilhante. São simples e fácil de entender. Quem lê, fica a saber a
> raíz por onde começou. Que é a melhor maneira de adquirir conhecimento.
>
> Um dos seus websites é: http://www-formal.stanford.edu/jmc/

Maravilha.  Vamos lembrar também que quando John McCarthy inventou Lisp,
ele não pensava na linguagem como uma linguagem de programação.  Foi
Steve Russell, orientando de John McCarthy que viu que o procedimento
/eval/ poderia e deveria virar um programa de computador.  Quando John
McCarthy ouviu a ideia direto do próprio Steve Russell, ele achou que o
Steve Russell estava viajando.  A história é contada pelo próprio
McCarthy.

[toc] | [prev] | [next] | [standalone]

Page 1 of 5  [1] 2 3 4 5  Next page →

Back to top | Article view | pt.comp.programacao

csiph-web