Re: [Gnoga-list] Gnoga's 10th anniversary - V2.2 released.

[Joakim Dahlgren Strandberg via Gnoga-list]

Congratulations to Gnoga's 10 year anniversary! Thank you Pascal for 
maintaining the source code and David Botton for starting the project and all 
other contributors!


Best regards,

Joakim Strandberg




Från: Pascal via Gnoga-list 
Skickat: den 8 september 2024 18:27:57
Till: Gnoga support list
Kopia: Pascal
Ämne: [Gnoga-list] Gnoga's 10th anniversary - V2.2 released.

Gnoga was born on SourceForge [1] on September 8, 2014.

Gnoga (GNU Omnificent Gui for Ada) is the multi-platform graphics library 
created natively in Ada.
I immediately liked Gnoga for the coherence and simplicity of these APIs 
naturally fitting together. The programmer can rely on Ada for his business 
code and on the multitude of Javascript libraries for the graphical interface.

For 10 years Gnoga has evolved in maturity to fulfill its founding principles:
- providing a framework and associated tools for developing GUI applications 
using the Ada language, leveraging web technologies for application developpers
- developing native applications for desktop and mobile just as easy to create, 
all using the same code base
- providing better tools means better application quality
- offering the application developer a powerful toolset for secure cloud based 
computing, mobile apps, desktop apps and web apps the combination not found in 
any other set of tools in any other language

Gnoga statistics:
- 1031 commits
- 2200 downloads
- 2196 posts on the mailing list
- 56 tickets

You'll find a special Gnoga's wiki anniversary page [2] with some materials and 
my testimony.

Feel free to post your testimony, your own story with Gnoga.

On this occasion, Gnoga V2.2a has been released [3] and [4], with main changes:
- Added key field to keyboard event
- If present command line options gnoga-host, gnoga-port, gnoga-boot and 
gnoga-verbose will override host, port, boot file and verbosity programmed in 
source code (see TIPS).
- Improve logging implementation in a separate package in order to allow user 
defined logging handlers.
- Add a backslash compatibility mode on the behavior of Escape_String for 
SQLite with the one for MySQL.
- Change MYSQL_Real_Connect profile to better match with documentation

This version has been tested on macOS 13.6 and GNAT 14.1. Please provide 
feedback of other environments.

[1] 
https://sourceforge.net/p/gnoga/code/ci/45c76779e7af7b869deacc698478eb3ef25cfe91
[2] https://sourceforge.net/p/gnoga/wiki/Gnoga-Anniversary
[3] https://sourceforge.net/projects/gnoga/files
[4] https://sourceforge.net/p/gnoga/code/ci/dev_2.2/tree

Regards, Pascal.



Regards, Pascal.



___
Gnoga-list mailing list
Gnoga-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gnoga-list
___
Gnoga-list mailing list
Gnoga-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gnoga-list

Re: [Gnoga-list] Gnoga soon on Alire.

[Joakim Dahlgren Strandberg]

I agree with David Botton, fantastic :)

Best regards,
Joakim

Sent from my iPhone

On 14 Jul 2022, at 21:36, David Botton  wrote:


Fantastic :)

On Thu, Jul 14, 2022 at 1:31 PM Blady via Gnoga-list 
mailto:gnoga-list@lists.sourceforge.net>> 
wrote:
Hello,

Many Ada programs are now available on Alire (https://alire.ada.dev/).
I plan to bring Alire support to Gnoga.
Thus it will be possible to get and build Gnoga from Alire with its dependences.

I'm waiting a while because Simple Components registered version in Alire is 
not compatible with latest GNAT compiler version.

Then I will to remove dependencies source codes (deps folder) from Gnoga 
repository.
That is  building with Alire will automatically manage dependencies; classic 
building will require to download dependencies and add them on GPR_PROJECT_PATH 
(README will be updated so).

What are your feedbacks?

Thanks, Pascal.
https://blady.pagesperso-orange.fr




___
Gnoga-list mailing list
Gnoga-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gnoga-list
___
Gnoga-list mailing list
Gnoga-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gnoga-list
___
Gnoga-list mailing list
Gnoga-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gnoga-list

Re: [Gnoga-list] Improvements/bugfixes.

[Joakim Dahlgren Strandberg]

Hi Joey,


I recommend looking into the example of an https server that is part of simple 
components (which is included in Gnoga):

components-connections_server-http_server-test_https_server.gpr


Example: You could have your simple components https server at port 8080 and it 
has two purposes.

  1.  Deliver the boot.html file that delivers the empty html file but that 
contains the Javascript code that connects the websocket that is part of Gnoga 
to the port where web sockets are expected to connect. You could put this web 
socket at port 8081.
  2.  The web server can also serve as a REST API to you your web application 
for whenever you need REST service features like being able to make POST 
requests to the web server/application.

I also recommend thinking about scalability and security. The Gnoga framework 
uses GNAT.Sockets for sockets and probably uses the select statement to know 
which TCP socket has received data:


Here is performance comparison (lower value is better):

# operations  |  poll  |  select   | epoll
10|   0.61 |0.73   | 0.41
100   |   2.9  |3.0| 0.42
1000  |  35|   35  | 0.53
1 | 990|  930  | 0.66

https://jvns.ca/blog/2017/06/03/async-io-on-linux--select--poll--and-epoll/

So if you make a web application you want to minize the number of simultaneous 
users of a socket. Above I wrote about having the Gnoga frameworks web-socket 
at port 8081. What you could have is several Gnoga web sockets, one at port 
8081, another on 8082, etc. So I don't recommend just delivering the boot.html 
file as it is because the web socket port is hard-coded to one value there. 
Deliver instead a custom boot.html file where the port number has been 
randomized and distribute your users evenly across the available TCP web 
sockets at the web server. It means you achieve load balancing without having 
an Apache server, as I believe David Botton has done.

Speaking of IT-security and Denial of Service attacks. I recommend to consider 
reserving a permanent web socket to each logged in user of a web site instead 
of having a permanent web socket to each browser that connects to the Gnoga web 
site. For a user that is not logged in the Gnoga web site could let the browser 
connect the web socket and then use it to build the HTML DOM and when finished 
disconnect the web socket.

Unfortunately I haven't had the time to develop the ideas presented above for 
making a web site but I believe it is doable and I hop you enjoyed sharing my 
thoughts on this subject.

Best regards,
Joakim

Från: Joey Fish 
Skickat: den 1 juni 2021 19:15:34
Till: Gnoga support list
Ämne: Re: [Gnoga-list] Improvements/bugfixes.


Blady,

   My use case is a online reporting-system, concerning what could be 
considered a multi-part/multiple-report system.

Functionally, I have a collection of DIVs containing settable elements 
(typically FORM-elements), which can be dragged into the report’s submission 
area, which then reads the DIV’s elements and adds them to the FORM for 
submission. (This allows e.g. multiple “observation” reports to be submitted, 
EOD.) — The issue here comes into play when the user has a lot of 
notations/comments to add, as this will make the ‘message’ text-area exceed the 
500 characters limitation.

   Much of the stuff could, eventually, be auto-generated, given an integrated 
redesign of the current system; this would entail much, much more and would be 
dealing with a very different set of operations (namely interfacing to various 
scientific instruments, taking the readings/data, collating & storing it; the 
reports in this scenario would then be essentially the metadata involved from 
these processes with the occasional user-notes).





From: Blady via Gnoga-list
Sent: Saturday, May 29, 2021 10:28
To: Gnoga support list
Cc: Blady
Subject: Re: [Gnoga-list] Improvements/bugfixes.



> Le 26 mai 2021 à 17:38, Joey Fish  a écrit :
>
> In handling form-data it was impossible to handle, via the HTML-Form POST 
> method, arbitrary parameters because lack of a filter ensured that no 
> parameters were processed. Following is the fix [in source-file 
> gnoga-server-connection.adb] I’ve been using, though this results in some 
> constraints for processing which prevent multi-user simultaneous access 
> (because post parameters are handled individually, therefore simultaneous 
> submissions cannot be handled).

<...>

> There is another limitation, one where any particular parameter cannot exceed 
> 500 characters, this limit is set in the definition Gnoga_HTTP_Content, in 
> the same source-file. Shown below.
>type Gnoga_HTTP_Content is new Content_Source with
>   record
>  Socket  : Socket_Type

Re: [Gnoga-list] [ANN] Gnoga version 1.6a and 2.1-beta.

[Joakim Dahlgren Strandberg]

Hello!


I have tried out Gnoga by git clone from the git repository and switched to the 
1.6 branch.


Executing gprbuild on the gnoga_secure.gpr file in gnoga/ssl/ causes gprbuild 
to crash.

gprbuild gnoga_secure.gpr
gprbuild: raised SYSTEM.ASSERTIONS.ASSERT_FAILURE : gpr-names.adb:206
[/opt/GNAT/2020/bin/gprbuild]
0x8985e0
0x67766d
0x5c3bdf
0x5c6dc3
0x5c83dd
0x5cb3a5
0x4b3aea
0x4a4474
[/lib/x86_64-linux-gnu/libc.so.6]
0x7f51be7d0bf5
[/opt/GNAT/2020/bin/gprbuild]
0x4a44c7


It crashes because the file settings.gpr is not found. By changing "with 
settings.gpr;" to "with ../settings.gpr" makes it possible to build the source 
code again. Maybe it was only me who have run into this issue but may be worth 
double checking.


OS: Ubuntu 18.04, Compiler: GNAT CE 2020


Best regards,

Joakim


Från: Blady via Gnoga-list 
Skickat: den 10 maj 2021 20:50:40
Till: Gnoga-list@lists.sourceforge.net
Kopia: Blady
Ämne: [Gnoga-list] [ANN] Gnoga version 1.6a and 2.1-beta.

Hello,

== Gnoga version 1.6a has been release on SF GIT:
https://sourceforge.net/p/gnoga/code/ci/dev_1.6/tree

Zipped source code will come soon at 
https://sourceforge.net/projects/gnoga/files.

See HISTORY for details:
https://sourceforge.net/p/gnoga/code/ci/dev_1.6/tree/HISTORY

== Version V2.1-beta has been released on SF GIT branch dev_2.1:
https://sourceforge.net/p/gnoga/code/ci/dev_2.1/tree

This version 2.1 is at the same level as 1.6 with in addition the support of 
dynamic Unicode strings via the UXStrings library 
(https://github.com/Blady-Com/UXStrings).

See HISTORY for detailed features added.
V2.1 has been tested (demos, tests, tutorials) with GNAT Community 2020 on 
macOS 11.2 with Safari 14.

I propose that new features will be added only on this version.
Bug fixes will be still added on version 1.6.

What do you think of going on 2.1?

Volunteers are welcome to test it further on their own configuration.
Some testing on Windows and Linux configuration will be appreciated.

Contributors are welcome.

Feel free to report detailed issues on Gnoga list or create tickets on SF:
https://sourceforge.net/p/gnoga/mailman/
https://sourceforge.net/p/gnoga/tickets/

Regards, Pascal.
https://blady.pagesperso-orange.fr




___
Gnoga-list mailing list
Gnoga-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gnoga-list
___
Gnoga-list mailing list
Gnoga-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gnoga-list

Re: [Gnoga-list] Rebuilding from scratch

[Joakim Dahlgren Strandberg]

Hi Chip,


I don't usually install Gnoga but download it into a directory and then in the 
project (gpr-file) that I create I with the gnoga/src/gnoga.gpr file. You may 
need to edit the gnoga.gpr file or some other file it depends upon in order to 
make the Ada code compile because it usually doesn't work out of the box, and 
it's because Gnoga wasn't intended to be used like that. It is my impression 
Gnoga is intended to be used through building all the Gnoga code and then 
install gnoga globally so that all Gnoga applications use one and the same 
version of Gnoga. I can imagine that the global installation of Gnoga has its 
spec files readonly and the package bodies are not included because the code 
has been pre-compiled into a static library. I prefer to be able to edit the 
Gnoga code directly, compile through the GPS and see the effect of the Gnoga 
code changes immediately and that each of my gnoga projects has its own version 
of Gnoga source code.


I hope you are successfull in your attempts to re-compile all the Ada code with 
one and the same Ada compiler. Perhaps it's a path issue?


Best regards,

Joakim


Från: Chip at Twirling Hall 
Skickat: den 10 maj 2021 03:07:23
Till: gnoga-list@lists.sourceforge.net
Ämne: [Gnoga-list] Rebuilding from scratch

I've cloned the repository and built (and run) tutorial_01.  I am now trying to 
integrate Gnoga into my GNAT project tree. I am getting errors that files must 
be recompiled because of different GNAT versions, but I can't figure out which 
of the existing Gnoga projects to use to make sure I get a clean build of 
everything.

Can someone point me to some info about how to build from scratch?

Thanks!
Chip Staples
Chief Engineer, Twirling Hall LLC
434-989-3995
c...@twirling-hall.com
___
Gnoga-list mailing list
Gnoga-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gnoga-list

Re: [Gnoga-list] Memory leak in Gnoga? False alarm?

[Joakim Dahlgren Strandberg]

And by the way, the compiler I am using is GNAT Community Edition 2019 and 
Ubuntu 18.04 in case I haven't mentioned it.

When running valgrind I write "valgring ./tutorial_03" in the bin/ directory.

Best regards,
Joakim
____
Från: Joakim Dahlgren Strandberg 
Skickat: den 12 november 2019 07:27
Till: Gnoga support list
Kopia: Pascal
Ämne: Re: [Gnoga-list] Memory leak in Gnoga? False alarm?

Hi Pascal,

Actually on second thoughts it's probably sufficient that I share the code for 
tutorial_03 I am using (a modified version of tutorial_03):


--  In the previous tutorials we created Singletons applications where there
--  is no issue of concurrency outside of events from the same user. This
--  allowed for programming in the familiar sequential patterns of regular
--  console applications. In this tutorial we will create an application that
--  will allow for multiple connections on the same machine, network or across
--  the globe on the internet.
--
--  In order to help see the different approach to setting up the application
--  we will do something similar to the previous tutorial.

with Ada.Exceptions;

with Gnoga.Application.Multi_Connect;
with Gnoga.Gui.Base;
with Gnoga.Gui.Window;
with Gnoga.Gui.View;
with Gnoga.Gui.Element.Common;

with Gnoga.Types;
--  Gnoga special types are found in Gnoga.Types.

procedure Tutorial_03 is

   --  Since this application will be used by multiple connections, we need to
   --  track and access that connection's specific data. To do this we create
   --  a derivative of Gnoga.Types.Connection_Data_Type that will be accessible
   --  to any object on a connection.

   type App_Data is new Gnoga.Types.Connection_Data_Type with
  record
 My_Window : Gnoga.Gui.Window.Pointer_To_Window_Class;
 My_View   : Gnoga.Gui.View.View_Type;
 My_Button : Gnoga.Gui.Element.Common.Button_Type;
 My_Exit   : Gnoga.Gui.Element.Common.Button_Type;
  end record;
   type App_Access is access all App_Data;

   procedure On_Click (Object : in out Gnoga.Gui.Base.Base_Type'Class);
   procedure On_Exit (Object : in out Gnoga.Gui.Base.Base_Type'Class);
   --  Events for our application. The implementation is almost identical
   --  to our previous tutorial. However we access the elements through our
   --  App_Data data structure associated with the connection instead of
   --  globally.

   procedure On_Click (Object : in out Gnoga.Gui.Base.Base_Type'Class) is
  App : constant App_Access := App_Access (Object.Connection_Data);
   begin
  App.My_View.New_Line;
  App.My_View.Put_Line ("I've been clicked!");
   end On_Click;

   procedure On_Exit (Object : in out Gnoga.Gui.Base.Base_Type'Class) is
  App : constant App_Access := App_Access (Object.Connection_Data);
  View : Gnoga.Gui.View.View_Type;
   begin
  App.My_View.Remove;
  View.Create (App.My_Window.all);
  View.Put_Line ("Application exited.");
  App.My_Window.Close_Connection;
  Gnoga.Application.Multi_Connect.End_Application;
   exception
   when E : others =>
 Gnoga.Log (Message => "On_Exit: " &
  Ada.Exceptions.Exception_Information (E));
   end On_Exit;

   procedure On_Connect
 (Main_Window : in out Gnoga.Gui.Window.Window_Type'Class;
  Connection  : access
Gnoga.Application.Multi_Connect.Connection_Holder_Type);
   --  Instead of creating and setting up our GUI in the main body of the
   --  application, we now set up the GUI in a connection event handler.
   --  The implementation is almost identical to the last tutorial except we
   --  place our GUI element variables within the App_Data data structure
   --  that will be associated with the connection.

   procedure On_Connect
 (Main_Window : in out Gnoga.Gui.Window.Window_Type'Class;
  Connection  : access
Gnoga.Application.Multi_Connect.Connection_Holder_Type)
   is
  pragma Unreferenced (Connection);
  App : constant App_Access := new App_Data;
   begin
  App.My_Window := Main_Window'Unchecked_Access;
  Main_Window.Connection_Data (App);
  --  This associates our application data to this connection. Now any
  --  object created on it has access to it using its Connection_Data
  --  property. When the connection is done it will deallocate the memory
  --  used.

  App.My_View.Create (Main_Window);

  App.My_Button.Create (App.My_View, "Click Me!");
  App.My_Button.On_Click_Handler (On_Click'Unrestricted_Access);

  App.My_Exit.Create (App.My_View, "Exit App");
  App.My_Exit.On_Click_Handler (On_Exit'Unrestricted_Access);

  App.My_View.Horizontal_Rule;
   end On_Connect;

begin
   Gnoga.Application.Title ("Tutorial 03");

   Gnoga.Application.HTML_On_Close ("Application ended.");

   G

Re: [Gnoga-list] Memory leak in Gnoga? False alarm?

[Joakim Dahlgren Strandberg]

 Setting Path to "default" means
   --  that any unmatched URL path will start that event handler. A URL path
   --  is the path following the host and port. For example:
   --  http://localhost:8080/test/me
   --  The Path would be "/test/me". In Gnoga the path can even appear to be
   --  a file name "/test/me.html". However if you have a file of the same
   --  name in the html directory it will be served instead.

   Gnoga.Application.Multi_Connect.Message_Loop;
end Tutorial_03;

Best regards,
Joakim


Från: Joakim Dahlgren Strandberg 
Skickat: den 12 november 2019 00:09
Till: Gnoga support list
Kopia: Pascal
Ämne: Re: [Gnoga-list] Memory leak in Gnoga? False alarm?

Hi Pascal,

Thanks for improving the memory leak situation. Before I did "git pull" to get 
the latest commits the result of valgrind was:
==2851==
==2851== HEAP SUMMARY:
==2851== in use at exit: 17,592 bytes in 19 blocks
==2851==   total heap usage: 574 allocs, 555 frees, 177,201 bytes allocated
==2851==

And after the memory leak fix commits:
==4220==
==4220== HEAP SUMMARY:
==4220== in use at exit: 10,520 bytes in 15 blocks
==4220==   total heap usage: 574 allocs, 559 frees, 177,201 bytes allocated
==4220==

And so the situation has been improved.

I will upload a reproducer on github tomorrow night to be able to reproduce my 
results. Too late to do it now. To be continued...

Best regards,
Joakim


Från: Pascal via Gnoga-list 
Skickat: den 11 november 2019 19:12
Till: Gnoga support list
Kopia: Pascal
Ämne: Re: [Gnoga-list] Memory leak in Gnoga? False alarm?

Hello Joakim,

> Le 3 nov. 2019 à 23:25, Joakim Dahlgren Strandberg  a écrit :
>
> Hi Pascal,
>
> Thanks for the detailed analysis of the potential memory leak. Seems it was a 
> treasure trove of issues to look at. I suspected there may be something 
> suspicious with some code in Dmitry's Simple Components but the code I looked 
> at appeared correct. Looking forward to hear more about the progress on this. 
> If I find out more I will share it here on the Gnoga mailing list of course.
>
> Best regards,
> Joakim
> 

...

> Hello Joakim,
>
> I have got detailed results from valgrind of memory leaks after Gnoga server 
> execution.
> There is 4 kinds of them:
> - allocation in globals that are not freed before exiting (Watchdog and 
> Gnoga_HTTP_Server) -> easy to fix

Fix.

> - allocation in GNAT RTE (initialization, Unbounded_String, String, 
> String_Access and exceptions) -> to be reported to AdaCore

Done for Unbounded_String.

> - allocation in HTTP server (container) -> to be reported to Dmitry

Fix.

> - allocation in Multi-Connect application for Connection_Data, user guide 
> said:
>  --  By default Connection_Data is assumed to be a dynamic object
>  --  and freed when the connection is closed.
> but it seems not to be the case -> investigation is needed.

Added a log: "Connection_Data freed", it seems then to be correct.

Changes are commited:
https://sourceforge.net/p/gnoga/code/ci/8bf88ff3c965689b2f097d1f4b0aab69cc75f9bd/

Could you please check with valgring if these leaks are still present or not?

Thanks, Pascal.
http://blady.pagesperso-orange.fr




___
Gnoga-list mailing list
Gnoga-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gnoga-list


___
Gnoga-list mailing list
Gnoga-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gnoga-list


___
Gnoga-list mailing list
Gnoga-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gnoga-list

Re: [Gnoga-list] Memory leak in Gnoga? False alarm?

[Joakim Dahlgren Strandberg]

Hi Pascal,

Thanks for improving the memory leak situation. Before I did "git pull" to get 
the latest commits the result of valgrind was:
==2851== 
==2851== HEAP SUMMARY:
==2851== in use at exit: 17,592 bytes in 19 blocks
==2851==   total heap usage: 574 allocs, 555 frees, 177,201 bytes allocated
==2851== 

And after the memory leak fix commits:
==4220== 
==4220== HEAP SUMMARY:
==4220== in use at exit: 10,520 bytes in 15 blocks
==4220==   total heap usage: 574 allocs, 559 frees, 177,201 bytes allocated
==4220== 

And so the situation has been improved.

I will upload a reproducer on github tomorrow night to be able to reproduce my 
results. Too late to do it now. To be continued...

Best regards,
Joakim


Från: Pascal via Gnoga-list 
Skickat: den 11 november 2019 19:12
Till: Gnoga support list
Kopia: Pascal
Ämne: Re: [Gnoga-list] Memory leak in Gnoga? False alarm?

Hello Joakim,

> Le 3 nov. 2019 à 23:25, Joakim Dahlgren Strandberg  a écrit :
>
> Hi Pascal,
>
> Thanks for the detailed analysis of the potential memory leak. Seems it was a 
> treasure trove of issues to look at. I suspected there may be something 
> suspicious with some code in Dmitry's Simple Components but the code I looked 
> at appeared correct. Looking forward to hear more about the progress on this. 
> If I find out more I will share it here on the Gnoga mailing list of course.
>
> Best regards,
> Joakim
> 

...

> Hello Joakim,
>
> I have got detailed results from valgrind of memory leaks after Gnoga server 
> execution.
> There is 4 kinds of them:
> - allocation in globals that are not freed before exiting (Watchdog and 
> Gnoga_HTTP_Server) -> easy to fix

Fix.

> - allocation in GNAT RTE (initialization, Unbounded_String, String, 
> String_Access and exceptions) -> to be reported to AdaCore

Done for Unbounded_String.

> - allocation in HTTP server (container) -> to be reported to Dmitry

Fix.

> - allocation in Multi-Connect application for Connection_Data, user guide 
> said:
>  --  By default Connection_Data is assumed to be a dynamic object
>  --  and freed when the connection is closed.
> but it seems not to be the case -> investigation is needed.

Added a log: "Connection_Data freed", it seems then to be correct.

Changes are commited:
https://sourceforge.net/p/gnoga/code/ci/8bf88ff3c965689b2f097d1f4b0aab69cc75f9bd/

Could you please check with valgring if these leaks are still present or not?

Thanks, Pascal.
http://blady.pagesperso-orange.fr




___
Gnoga-list mailing list
Gnoga-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gnoga-list


___
Gnoga-list mailing list
Gnoga-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gnoga-list

Re: [Gnoga-list] Memory leak in Gnoga? False alarm?

[Joakim Dahlgren Strandberg]

Hi Pascal,

Thanks for the detailed analysis of the potential memory leak. Seems it was a 
treasure trove of issues to look at. I suspected there may be something 
suspicious with some code in Dmitry's Simple Components but the code I looked 
at appeared correct. Looking forward to hear more about the progress on this. 
If I find out more I will share it here on the Gnoga mailing list of course.

Best regards,
Joakim

Från: Pascal 
Skickat: den 1 november 2019 21:25
Till: Joakim Dahlgren Strandberg
Kopia: Gnoga support list
Ämne: Re: [Gnoga-list] Memory leak in Gnoga? False alarm?

> Le 31 août 2019 à 22:18, Joakim Dahlgren Strandberg  a écrit 
> :
>
> Hi Pascal,
>
> Thanks for taking a look at the memory leak issue. I ran valgrind on 
> tutorial_03. But I did make an adjustment to the On_Exit procedure to be able 
> to stop the gnoga application:
>
>   procedure On_Exit (Object : in out Gnoga.Gui.Base.Base_Type'Class) is
>  App : constant App_Access := App_Access (Object.Connection_Data);
>  View : Gnoga.Gui.View.View_Type;
>   begin
>  App.My_View.Remove;
>  View.Create (App.My_Window.all);
>  View.Put_Line ("Application exited.");
>  App.My_Window.Close_Connection;
>  Gnoga.Application.Multi_Connect.End_Application;--  < Just added 
> this line
>   exception
>   when E : others =>
> Gnoga.Log (Message => "On_Exit: " &
>  Ada.Exceptions.Exception_Information (E));
>   end On_Exit;
>
> My platform is Ubuntu 18.04. Here is output from valgrind:
>
> ~/projects/gnoga-code/bin$ valgrind ./tutorial_03
> ==916== Memcheck, a memory error detector
> ==916== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
> ==916== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
> ==916== Command: ./tutorial_03
> ==916==
> Gnoga:1.5-beta
> Application root :/home/joakim/projects/gnoga-code/
> Executable at:/home/joakim/projects/gnoga-code/bin/
> HTML root:/home/joakim/projects/gnoga-code/html/
> Upload directory :/home/joakim/projects/gnoga-code/upload/
> Templates root   :/home/joakim/projects/gnoga-code/templates/
> /js  at  :/home/joakim/projects/gnoga-code/js/
> /css at  :/home/joakim/projects/gnoga-code/css/
> /img at  :/home/joakim/projects/gnoga-code/img/
> Boot file:boot.html
> HTTP listen on   ::8080
> Multi-connect application.
> Press Ctrl-C to close server.
> 2019-08-31 22:08:10.62 : HTTP Server Started
> 2019-08-31 22:08:15.47 : Requested: Kind: FILE, File: , Query:
> 2019-08-31 22:08:15.55 : Reply: 
> /home/joakim/projects/gnoga-code/html/boot.html (text/html)
> 2019-08-31 22:08:15.57 : Requested: Kind: FILE, File: js/jquery.min.js, Query:
> 2019-08-31 22:08:15.58 : Reply: 
> /home/joakim/projects/gnoga-code/js/jquery.min.js (text/javascript)
> 2019-08-31 22:08:15.60 : Requested: Kind: FILE, File: js/boot.js, Query:
> 2019-08-31 22:08:15.60 : Reply: /home/joakim/projects/gnoga-code/js/boot.js 
> (text/javascript)
> 2019-08-31 22:08:15.74 : New connection - ID 1
> 2019-08-31 22:08:16.34 : Sending to default route for Mozilla/5.0 (X11; 
> Ubuntu; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0 on Linux x86_64 
> from 127.0.0.1:53526
> 2019-08-31 22:08:19.84 : Deleting connection - 1
> 2019-08-31 22:08:19.92 : HTTP Server Stopping
> ==916==
> ==916== HEAP SUMMARY:
> ==916== in use at exit: 17,592 bytes in 19 blocks
> ==916==   total heap usage: 574 allocs, 555 frees, 177,185 bytes allocated
> ==916==
> ==916== LEAK SUMMARY:
> ==916==definitely lost: 3,104 bytes in 4 blocks
> ==916==indirectly lost: 0 bytes in 0 blocks
> ==916==  possibly lost: 0 bytes in 0 blocks
> ==916==still reachable: 14,488 bytes in 15 blocks
> ==916== suppressed: 0 bytes in 0 blocks
> ==916== Rerun with --leak-check=full to see details of leaked memory
> ==916==
> ==916== For counts of detected and suppressed errors, rerun with: -v
> ==916== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Hello Joakim,

I have got detailed results from valgrind of memory leaks after Gnoga server 
execution.
There is 4 kinds of them:
- allocation in globals that are not freed before exiting (Watchdog and 
Gnoga_HTTP_Server) -> easy to fix
- allocation in GNAT RTE (initialization, Unbounded_String, String, 
String_Access and exceptions) -> to be reported to AdaCore
- allocation in HTTP server (container) -> to be reported to Dmitry
- allocation in Multi-Connect application for Connection_Data, user guide said:
  --  By default Connection_Data is assumed to be a dynamic object
  --  and freed when the connection is closed.
but it seems not to be the case -> investigation is needed.

Regards, Pascal.
http://blady.pagesperso-orange.fr




___
Gnoga-list mailing list
Gnoga-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gnoga-list

Re: [Gnoga-list] File upload

[Joakim Dahlgren Strandberg]

Hi Henrik,


I am since yesterday working on the same issue, namely file upload. There is an 
example on how to do that in forms.adb which can be found in the demo 
directory. The application forms.adb demonstrates traditional post requests to 
the server forcing a full reload of the web page. But the example code there is 
good to get started.


I have been experimenting with making AJAX request to the server by using the 
following approach (hopefully the code is inspirational, I would prefer sending 
a complete code example of forms.adb with the file upload without complete page 
refresh but it is more than a thousand lines of code and not suitable for 
e-mail):


Gnoga.Server.Connection.Execute_Script
 (ID => Main_Window.Connection_ID,
  Script =>
"var uploadRequest = new XMLHttpRequest();" &
"uploadRequest.open('post', window.location.href + 
'demo');" &
"var file = document.getElementById('" &
Upload_File_Input.ID & "').files[0];" &
"var fd = new FormData();" &
"fd.append(""fn"", file);" &
"uploadRequest.send(fd);");


However, trigggering file upload using XMLHttpRequest causes the uploaded file 
to be corrupted or bytes are missing in the resulting uploaded file. Hopefully 
somebody in the Gnoga mailing list has been more successful. Currently I do 
recommend uploading a file with complete page refresh as in forms.adb because 
it works.


Best regards,

Joakim



Från: Henrik Härkönen 
Skickat: den 1 oktober 2019 09:54
Till: Gnoga support list
Ämne: [Gnoga-list] File upload

Hello!

I'm not very experienced yet with Gnoga (or with Ada for that matter), but I 
was planning to make this little tool for the choir I'm singing in, which would 
involve the user to send a PDF files to the app and then it would do "things" 
with it and return some result file.

How would one go about adding a file upload functionality with Gnoga? I browsed 
briefly through the API, but nothing related to it was caught by my eye.


Best regards,
Henrik.
___
Gnoga-list mailing list
Gnoga-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gnoga-list

Re: [Gnoga-list] Memory leak in Gnoga? False alarm?

[Joakim Dahlgren Strandberg]

Hi Pascal,

Thanks for taking a look at the memory leak issue. I ran valgrind on 
tutorial_03. But I did make an adjustment to the On_Exit procedure to be able 
to stop the gnoga application:

   procedure On_Exit (Object : in out Gnoga.Gui.Base.Base_Type'Class) is
  App : constant App_Access := App_Access (Object.Connection_Data);
  View : Gnoga.Gui.View.View_Type;
   begin
  App.My_View.Remove;
  View.Create (App.My_Window.all);
  View.Put_Line ("Application exited.");
  App.My_Window.Close_Connection;
  Gnoga.Application.Multi_Connect.End_Application;--  < Just added 
this line  
   exception
   when E : others =>
 Gnoga.Log (Message => "On_Exit: " &
  Ada.Exceptions.Exception_Information (E));
   end On_Exit;

My platform is Ubuntu 18.04. Here is output from valgrind:

~/projects/gnoga-code/bin$ valgrind ./tutorial_03 
==916== Memcheck, a memory error detector
==916== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==916== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==916== Command: ./tutorial_03
==916== 
Gnoga:1.5-beta
Application root :/home/joakim/projects/gnoga-code/
Executable at:/home/joakim/projects/gnoga-code/bin/
HTML root:/home/joakim/projects/gnoga-code/html/
Upload directory :/home/joakim/projects/gnoga-code/upload/
Templates root   :/home/joakim/projects/gnoga-code/templates/
/js  at  :/home/joakim/projects/gnoga-code/js/
/css at  :/home/joakim/projects/gnoga-code/css/
/img at  :/home/joakim/projects/gnoga-code/img/
Boot file:boot.html
HTTP listen on   ::8080
Multi-connect application.
Press Ctrl-C to close server.
2019-08-31 22:08:10.62 : HTTP Server Started
2019-08-31 22:08:15.47 : Requested: Kind: FILE, File: , Query: 
2019-08-31 22:08:15.55 : Reply: /home/joakim/projects/gnoga-code/html/boot.html 
(text/html)
2019-08-31 22:08:15.57 : Requested: Kind: FILE, File: js/jquery.min.js, Query: 
2019-08-31 22:08:15.58 : Reply: 
/home/joakim/projects/gnoga-code/js/jquery.min.js (text/javascript)
2019-08-31 22:08:15.60 : Requested: Kind: FILE, File: js/boot.js, Query: 
2019-08-31 22:08:15.60 : Reply: /home/joakim/projects/gnoga-code/js/boot.js 
(text/javascript)
2019-08-31 22:08:15.74 : New connection - ID 1
2019-08-31 22:08:16.34 : Sending to default route for Mozilla/5.0 (X11; Ubuntu; 
Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0 on Linux x86_64 from 
127.0.0.1:53526
2019-08-31 22:08:19.84 : Deleting connection - 1
2019-08-31 22:08:19.92 : HTTP Server Stopping
==916== 
==916== HEAP SUMMARY:
==916== in use at exit: 17,592 bytes in 19 blocks
==916==   total heap usage: 574 allocs, 555 frees, 177,185 bytes allocated
==916== 
==916== LEAK SUMMARY:
==916==definitely lost: 3,104 bytes in 4 blocks
==916==indirectly lost: 0 bytes in 0 blocks
==916==  possibly lost: 0 bytes in 0 blocks
==916==still reachable: 14,488 bytes in 15 blocks
==916== suppressed: 0 bytes in 0 blocks
==916== Rerun with --leak-check=full to see details of leaked memory
==916== 
==916== For counts of detected and suppressed errors, rerun with: -v
==916== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Best regards,
Joakim

Från: Pascal via Gnoga-list 
Skickat: den 31 augusti 2019 21:18
Till: Gnoga support list
Kopia: Pascal
Ämne: Re: [Gnoga-list] Memory leak in Gnoga? False alarm?

> Le 29 août 2019 à 11:56, Joakim Dahlgren Strandberg  a écrit 
> :
>
> Hi,
>
> I've used valgrind on tutorial-03 and as far as I can tell Gnoga seems to 
> leak memory. To do it I've added
>   Gnoga.Application.Multi_Connect.End_Application;
> in one of the button click handlers to make it possible to stop the Gnoga web 
> server without using ctrl+c. Is there someone that can verify or refute that 
> memory is being leaked? Evidently David has been running Gnoga web servers 
> for long periods of time (for example http://www.gnoga.com) without memory 
> leak issue but still it would be nice if one could understand why valgrind is 
> reporting that not all memory has been reclaimed when the gnoga web server 
> has shutdown.

Hello Joakim,

I've just do:
$ valgrind bin/plot_test
==27673== Memcheck, a memory error detector
==27673== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==27673== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==27673== Command: bin/plot_test
...

But Gnoga server is not starting.
Which command do you use?
What is your configuration?
I use GNAT Community 2019 on macOS 10.13.

Thanks, Pascal.
http://blady.pagesperso-orange.fr


___
Gnoga-list mailing list
Gnoga-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gnoga-list

[Gnoga-list] Memory leak in Gnoga? False alarm?

[Joakim Dahlgren Strandberg]

Hi,


I've used valgrind on tutorial-03 and as far as I can tell Gnoga seems to leak 
memory. To do it I've added

  Gnoga.Application.Multi_Connect.End_Application;

in one of the button click handlers to make it possible to stop the Gnoga web 
server without using ctrl+c. Is there someone that can verify or refute that 
memory is being leaked? Evidently David has been running Gnoga web servers for 
long periods of time (for example http://www.gnoga.com) 
without memory leak issue but still it would be nice if one could understand 
why valgrind is reporting that not all memory has been reclaimed when the gnoga 
web server has shutdown.


Best regards,

Joakim
___
Gnoga-list mailing list
Gnoga-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gnoga-list

[Gnoga-list] On support for font awesome icons

[Joakim Dahlgren Strandberg]

Hi,


In some web applications one may be interested in using free icons from Font 
Awesome:


https://fontawesome.com/


To use these fonts it is described in the documentation to take advantage of 
Font Awesome's CDN servers that provide the minimified font-awesome.min.css 
file. If one would like to host this css file on one's own Gnoga server it is 
not sufficient to download font-awesome.min.css and put in the /css directory. 
The file font-awesome.min.css also expects to find font files in a directory 
/fonts. It is not sufficient to download these fonts, create a directory /fonts 
and put the font files there one also needs to instruct Gnoga to mirror the 
/fonts directory. To do that one solution is to edit the subprogram 
Gnoga.Server.Connection.Do_Get_Head and specify there that /fonts URLs should 
mirror the /fonts directory just as for example the /css, /img and /js 
directories. Perhaps it would be cooler if one could somehow specify to the 
Gnoga framework which directories should be mirrored instead of having it 
hard-coded in the Do_Get_Head procedure. If the majority of the stake holders 
in the Gnoga mailing list agree then I suggest that we create a ticket for this.


Best regards,

Joakim
___
Gnoga-list mailing list
Gnoga-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gnoga-list

[Gnoga-list] Placement of a button tag inside list-item tag

[Joakim Dahlgren Strandberg]

Hi,


To place a button inside a div tag one can write


declare

  View : Gnoga.Gui.View.View_Type;

   Button : Gnoga.Gui.Element.Common.Button_Type;

begin

   ...

   Button.Create (Parent => View);

end;


The result is



   




Consider the situation when one would like to place a button inside a list item 
tag:



   

   

   




It is then not sufficient to use Button.Create (Parent => My_List_Item) where 
My_List_Item is of the type Gnoga.Gui.Element.List.List_Item_Type. One will 
need to use an explicit call:

   Button.Place_Inside_Bottom_Of (Target => My_List_Item);


Is this by design or is it a mistake? One should be able to put buttons inside 
list item tags using the Create subprogram but it is not implemented?


Best regards,

Joakim
___
Gnoga-list mailing list
Gnoga-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gnoga-list

[Gnoga-list] On stopping propagation of click events in the DOM

[Joakim Dahlgren Strandberg]

Hi everyone,

Lately I've started looking into Gnoga again for web development.
Sad to hear about Davids health issue but glad he feels better and on the road 
to recovery.
I recently ran into the issue of mouse click event propagation.
What is the best way to stop mouse clicks to bubble up the DOM
in one's application? I've successfully used the hack that was
suggested by Olivier (after David had suggested something similar).
There is also a comment by David on improving the situation in 2015.
My guess is that the hack is still the best way to go about it.
I've added the following subprogram in my project:

   procedure Connect_Click_Handler
 (Element : in out Gnoga.Gui.Base.Base_Type'Class;
  Handler : in Gnoga.Gui.Base.Action_Event) is
   begin
  Element.On_Click_Handler (Handler => Handler);
  Element.Bind_Event_Script
(Event  => "click",
 Script => "e.stopPropagation()");
   end Connect_Click_Handler;

It works for me but would be cool if there was some subprogram
in Gnoga one could call directly instead of making two
subprogram calls to the Gnoga framework.

Best regards,
Joakim

> 2015-12-02 03:04:45
>
> It should be doable to add a Propagate_Events property in Gnoga.Gui.Base,
> I'll add it soon.
>
> David Botton


On Tue, Dec 1, 2015 at 9:29 PM Olivier Henley 
wrote:

> No it did not.
>
> ... but found a hack that works, namely binding a script, at creation, to
> stop propagation directly at the browser level:
>
> Trash_Div.On_Click_Handler (App.Controller.On_Click_Trash_Clip'Access);
>
> Trash_Div.Bind_Event_Script (Event  => "click",
>Script =>
> "e.stopPropagation()");
>
> Thx.

___
Gnoga-list mailing list
Gnoga-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gnoga-list

[Gnoga-list] Further thoughts on the selectmenu

[Joakim Dahlgren Strandberg]

Hi all Gnoga Users!

In a previous e-mail I wrote about the selectmenu using jquery ui. The issue 
with that piece of code that I sent is in the procedure:

procedure Make_Select_Menu
 (Element: in out Gnoga.Gui.Element.Form.Selection_Type'Class;
  On_Changed_Handler : in Base.Action_Event)
   is
  US : constant String := Element.Unique_ID'Img;

  Unique_Id : constant String := US (US'First + 1 .. US'Last);
  Mouse_Event_Script : constant String := "";
   begin
  Element.On_Change_Handler (On_Changed_Handler);
  Element.jQuery_Execute ("selectmenu({ change: function( e, data ){ 
ws.send (""" & Gnoga.Escape_Quotes (Unique_ID & "|change|") & """); } })");
   end Make_Select_Menu;

Notice the line "Element.On_Change_Handler (On_Changed_Handler);". It binds to 
the "change" event on the selectmenu.
This event is never fired, at least to my experience.
According to the documentation (http://api.jqueryui.com/selectmenu/) it is 
"selectmenuchange" event
that should be subscribed for if one wishes to receive notifications of when 
the user has changed a selection.
The unnecessary code that is being executed in the "Element.On_Change_Handler 
(On_Changed_Handler);" is the binding to the change event,
but the useful thing is setting up the event handler i.e. one would like to set 
up the event handler but not subscribe
to the "change" event. The implementation of Gnoga.Gui.Base.On_Change_Handler 
is in the package Gnoga.Gui.Base and it's implementation is hidden
because the code for plugin bindings is not in a child package. It is thus not 
possible to create a custom implementation that
only sets up the event handler but does not subscribe to the "change" event. 
Maybe one would like the Plugin bindings to be
a child package of the Gnoga.Gui.Base package? Of course that is not the 
perfect solution neither in this case since
the selectmenu (jquery ui version) has a new event called "selectmenuchange", 
and one would like to create a specific
eventhandler for this event. Anyways, the issue of selectmenu raises questions 
about the architecture of the Gnoga framework,
the sense of "Has this been thought about?", if no "What do we need to do about 
it?", if yes "What is the standard solution for this contingency?".

Best regards,
Joakim Strandberg
--
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140___
Gnoga-list mailing list
Gnoga-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gnoga-list

[Gnoga-list] Suggestion for additional procedures for jquery ui selectmenus

[Joakim Dahlgren Strandberg]

Hi all Gnoga Users!


The current implementation for a selectmenu using jquery ui supports a workflow 
where one first creates the selectmenu, and then populates it with options and 
in the final step call Make_Select_Menu to apply the jquery ui style change. It 
is not possible to receive notifications when a user selects an option (at 
least I could not receive notifications when using a On_Change_Handler nor 
On_Click_Handler). Also updating the selectmenu with new options or removing 
previously added ones is not reflected in the browser. I suggest adding the 
following procedures to the

Gnoga.Gui.Plugin.jQueryUI.Widget package to fix these limitations (the code is 
not perfect but gets the job done):


   -- Call this procedure to receive notifications when selected option changes.
   procedure Make_Select_Menu
 (Element: in out Gnoga.Gui.Element.Form.Selection_Type'Class;
  On_Changed_Handler : in Base.Action_Event);

   -- Assuming Make_Select_Menu already has already been called on the select 
menu.
   -- If the options are changed afterward, call this procedure to make
   -- changes visible in the browser.
   procedure Refresh_Select_Menu
 (Element : in out Gnoga.Gui.Element.Form.Selection_Type'Class);

   -- Assuming Make_Select_Menu already has already been called on the select 
menu.
   -- Deletes all elements in a select menu.
   -- To make the change visible in the browser call Refresh_Select_Menu.
   -- The "normal" usage is to remove all options in the select menu and
   -- then populate it again with options and then call Refresh_Select_Menu.
   procedure Clear_Select_Menu
 (Element : in out Gnoga.Gui.Element.Form.Selection_Type'Class);


   procedure Make_Select_Menu
 (Element: in out Gnoga.Gui.Element.Form.Selection_Type'Class;
  On_Changed_Handler : in Base.Action_Event)
   is
  US : constant String := Element.Unique_ID'Img;

  Unique_Id : constant String := US (US'First + 1 .. US'Last);
  Mouse_Event_Script : constant String := "";
   begin
  Element.On_Change_Handler (On_Changed_Handler);
  Element.jQuery_Execute ("selectmenu({ change: function( e, data ){ 
ws.send (""" & Gnoga.Escape_Quotes (Unique_ID & "|change|") & """); } })");
   end Make_Select_Menu;

   procedure Refresh_Select_Menu
 (Element : in out Gnoga.Gui.Element.Form.Selection_Type'Class)
   is
   begin
  Element.jQuery_Execute ("selectmenu('refresh')");
   end Refresh_Select_Menu;

   procedure Clear_Select_Menu
 (Element : in out Gnoga.Gui.Element.Form.Selection_Type'Class)
   is
   begin
  Element.jQuery_Execute ("find('option').remove().end();");
   end Clear_Select_Menu;


I've tried to be true to the Ada code style applied to the Gnoga library. What 
do you think?


Best regards,

Joakim Strandberg
--
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140___
Gnoga-list mailing list
Gnoga-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gnoga-list

Re: [Gnoga-list] tabs and cards

[Joakim Dahlgren Strandberg]

>> Does anyone have an example of a simple tabbed application?

>>

>> Björn


Dear Björn,


Have you checked the test/tree.adb application? It is written by David Botton 
and demonstrates mnmenu (in addition to how to use jstree).


Best regards,

Joakim Strandberg
--
___
Gnoga-list mailing list
Gnoga-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gnoga-list

Re: [Gnoga-list] Enhancing Exception Handling Suggestion

[Joakim Dahlgren Strandberg]

> On 2015-08-07 00:09, Joakim Dahlgren Strandberg wrote:
> >
> > While we are on the subject on exceptions. There is no way to get stack
> > trace information if one uses GNAT GPL 2015, right? I mean, there is no
> > addr2line.
>
> I have addr2line. You do not mention platform though.



Thanks all for responding. The platform I am working on is Mac OS X. I've been 
looking into this and addr2line does not exist on the Mac. Instead one should 
use an application called atos. Thus I've finally been able to get a nice stack 
trace when an application threw an exception. Something that worries me though 
is that when using atos there is a message saying that atos is obsolete and 
will not be included in a future version of Mac OS X. Googling about it has not 
turned up any alternatives. Anyways, getting stack traces works for me now, and 
I regard atos potentially disappearing a problem of the future.
--
___
Gnoga-list mailing list
Gnoga-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gnoga-list

Re: [Gnoga-list] Enhancing Exception Handling Suggestion

[Joakim Dahlgren Strandberg]

-- During exception handling, use function
-- Ada.Exceptions.Exception_Information(EO) instead of Ada.Exception_Name (EO)
-- & Ada.Exception_Message (EO). Of course, EO stands for Exception_Occurrence
-- type. The advantage of this usage is that Exception_Information has all
-- capabilities of Exception_Name and Exception_Message combined. In addition,
-- function Exception_Information also gives full call stack trace back for
-- most platforms.
--
-- Anh Vo


I agree with the above at least for the GNAT compiler. I remember advocating 
this view, but then someone (could it have been Tero Koskinen who has 
experience with several different Ada compilers?) informed me that the Ada 
standard has more restrictions on what Ada.Exception_Name (EO) and 
Ada.Exception_Message (EO) contains and that there is less restriction on what 
Exception_Information should contain. The argumentation was that if one wants 
to be cross-compiler one should stick to Exception_Name and Exception_Message 
for the application to exhibit similar exception error messages. My experience 
is that Exception_Information with the GNAT compiler works as described above 
and works very well.


While we are on the subject on exceptions. There is no way to get stack trace 
information if one uses GNAT GPL 2015, right? I mean, there is no

addr2line.


By the way, in an earlier post I wrote about some issue in the HTTP Client 
implementation in simple compnonents. I can report that it works very well.


Best regards,

Joakim Strandberg
--
___
Gnoga-list mailing list
Gnoga-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gnoga-list

[Gnoga-list] Accept header still not included in GET request

[Joakim Dahlgren Strandberg]

Thanks for the message a couple days ago:

-- Try the latest version now in git which also has an https client in
-- addition to http.
--
-- Thanks!
-- David Botton

Wow, that's amazing there is also a https client available. I didn't expect 
something like that being implemented in the near future. Mr. Dmitry is 
prolific as usual :-)


I can still report though that the ACCEPT header is still not being sent with a 
GET request. One application is extracting information from Open Data sources, 
like for example http://www.opengov.se/data/


To demonstrate this I've written som Ada code that downloads the html response 
when sending a GET request to www.google.se:

https://github.com/joakim-strandberg/http_client


When executing the it successfully downloads the HTML code, and part of the 
output can be read below. What one can see though is that the following headers 
are sent ACCEPT_ENCODING_HEADER, ACCEPT_LANGUAGE_HEADER, HOST_HEADER, 
USER_AGENT_HEADER, but not the ACCEPT header. What I believe is the problem is 
the following line:

Send_Headers (Data.Header, Integer (Data.Count));

It can be found on line 2800, in file

gnat-sockets-connection_state_Machine-http_client.adb

As I understand the code there is an enumeration type called Request_Header 
that identifies the different headers, and as we now each member identifier of 
an enumeration type is represented by an integer. What these integers are is 
not explicitly specified in the code but I believe the gcc compiler assigns 
each identifier a unique integer starting from zero. The Data.Header is an 
integer that keeps track on the headers that already has been sent to the 
server receiving the GET request. If Data.Header := 5 it means that all headers 
in the enumeration type represented by integers less than 5 already has been 
sent.

The first time Send_Headers is called for a request Data.Header := 1, which 
means that the code will start trying to send the Accept_Charset_Header -header 
which is assigned the integer 1. However, Accept_Header is assigned zero and 
thus will never be sent.


Why does Data.Header start from 1 and not 0? I have made a quick-fix locally on 
my machine to test what happens when Data.Header starts from 0 instead of 1 and 
then I finally was successfull in downloading information from an Open Data API 
that required the ACCEPT header to be present in the GET request. That's why 
I'm pretty sure the code in simple components need to be adjusted. The question 
that remains is what? There are a couple of solutions that come to mind. One is 
to assign values to the member identifiers of the Request_Header enumeration 
type, starting from 1 (I have not tried it but there's a chance that it might 
work). Another is to figure out why the Data.Header starts from 1 instead of 0. 
Maybe this is as designed? Maybe there is a good reason for this? Anyways, 
thanks for reading. And thanks Dmitry for your good work. And thanks David for 
your work on Gnoga.


/Users/joakimstrandberg/projects/http_client/obj/main
HTTP client started
64.233.161.94:80 < --- Stop polling, connecting to ...
64.233.161.94:80 < --- Stop polling, connected
64.233.161.94:80 < --- Stop polling, nothing to send
HTTP client connected to httpbin.org
64.233.161.94:80 < +++ Resume polling, some data to send
64.233.161.94:80 < |GET http://www.google.se HTTP/1.1%0D%0AConnection: 
close%0D%0ADate: Sat, 30 May 2015 20:| 0..79
begin 1
ACCEPT_ENCODING_HEADER gzip, deflate
ACCEPT_LANGUAGE_HEADER sv-SE,sv;q=0.8,en-US;q=0.5,en;q=0.3
end 3
64.233.161.94:80 < |2| 80..80
64.233.161.94:80 < |0:41 +0200%0D%0AAccept-Encoding: gzip, 
deflate%0D%0AAccept-Language: sv-SE,sv;q=0.8,en-| 0..78
begin 3
ACCEPT_LANGUAGE_HEADER sv-SE,sv;q=0.8,en-US;q=0.5,en;q=0.3
HOST_HEADER www.google.se
USER_AGENT_HEADER Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) 
Gecko/20100101 Firefox/38.0
end 31
64.233.161.94:80 < |US| 79..80
64.233.161.94:80 < |;q=0.5,en;q=0.3%0D%0AHost: www.google.se%0D%0AUser-Agent: 
Mozilla/5.0 (Macintosh; Inte| 0..77
begin 31
USER_AGENT_HEADER Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) 
Gecko/20100101 Firefox/38.0
end 45
64.233.161.94:80 < |l M| 78..80
64.233.161.94:80 < |ac OS X 10.9; rv:38.0) Gecko/20100101 
Firefox/38.0%0D%0A%0D%0A| 0..53
64.233.161.94:80 < --- Stop polling, nothing to send

--
___
Gnoga-list mailing list
Gnoga-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gnoga-list

[Gnoga-list] Accept headers are not sent in GET requests

[Joakim Dahlgren Strandberg]

Hi all on the Gnoga mailing list,

"The test is ./test_components/test_http_client.adb"

The 15:th of May (4 days ago), Dmitry sent an implementation of an HTTP client 
to David who wrote about it here on the mailing list.
I tried it out yesterday night and discovered that the Accept header is missing 
in GET requests (assuming one has specified it of course).
To see this, look at the procedure with a name that ends with Get_1, and set 
the Accept header.
In the print out of what's being sent one can see that whatever one sets the 
accept header to, it's not included.
Due to lack of time I have not been able to produce a solution (but it was very 
entertaining to get an insight into the details of the implementation!).

Best regards,
Joakim Strandberg

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Gnoga-list mailing list
Gnoga-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gnoga-list