Re: [Gnoga-list] Errors in Gnoga.Gui.Element.Canvas.Context_2d
> Le 12 mars 2024 à 13:37, Wayne Bullaughey via Gnoga-list > a écrit : > > Soon after my application starts a call to Swap_Connection occurs. Within 60 > seconds of that I get the following: > > 2024-03-12 08:28:17.87 : Deleting connection - 2 > 2024-03-12 08:28:17.88 : Watchdog error. > 2024-03-12 08:28:17.88 : raised ADA.ASSERTIONS.ASSERTION_ERROR : Position > cursor of Next is bad > Load address: 0x1027bf000 > Call stack traceback locations: > 0x102b45091 0x102a1d6e0 0x102a3929b 0x102a3931f 0x102a402d6 0x102b0d008 > 0x7ff8053f7200 > > I prevented this from happening by adding the following lines in the > procedure Delete_Connection in the file gnoga-server-connection.adb. > > if Socket_Maps.Key (Current_Socket) = ID then > Current_Socket := Socket_Maps.No_Element; > end if; > > After the line: > > if Socket_Map.Contains (ID) then Hello Wayne, Which is your Gnoga version running? It reminds me an old issue with Watchdog. Regards, Pascal. ___ Gnoga-list mailing list Gnoga-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gnoga-list
Re: [Gnoga-list] Errors in Gnoga.Gui.Element.Canvas.Context_2d
> Le 21 mars 2024 à 21:07, Wayne Bullaughey via Gnoga-list > a écrit : > > gnoga.ads has 1.2b. Is that the official version? Hello Wayne, Gnoga 1.2 is the last version from archive. You can get version 1.6a stable with GIT: https://sourceforge.net/p/gnoga/code/ci/V1.6a/tree/ Versions 1.x will have only error fixes. Or switch to version 2.1a stable from archive: https://sourceforge.net/projects/gnoga/files/gnoga-2.1a.zip/download Versions 2.x have Unicode support and are the ongoing dev. Regards, Pascal. ___ Gnoga-list mailing list Gnoga-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gnoga-list
Re: [Gnoga-list] Errors in Gnoga.Gui.Element.Canvas.Context_2d
> Le 25 nov. 2023 à 19:58, Jeffrey R. Carter via Gnoga-list > a écrit : > > On 25 November 2023 18:49:46 UTC, Blady wrote: >> >> >>> Le 18 nov. 2023 à 21:26, J Carter a écrit : >>> I've upgraded Simple Components in dev_1.8 branch: https://sourceforge.net/p/gnoga/code/ci/dev_1.8/tree/ I've tested ok with GNAT FSF 13.2 from Alire. >>> >>> That compiles. Attached is a reproducer, data_error.adb, and corresponding >>> project file (edit the path to gnoga.gpr as needed). >>> I've capture the javascript string: >>> Array.prototype.join.call (gnoga['g12'].data) >> < >> "255,0,0,255,255,0,0,255,255,0,0,255,255,0,0,255,0,128,0,254,0,128,0,255,0,128,0,255,0,128,0,254,0,0,252,252,0,0,255,255,0,0,255,255,0,0,252,252" >> >> The documentation says: >> ImageData.data Read only A Uint8ClampedArray representing a one-dimensional >> array containing the data in the RGBA order, with integer values between 0 >> and 255 (inclusive). The order goes by rows from the top-left pixel to the >> bottom-right. >> (https://developer.mozilla.org/en-US/docs/Web/API/ImageData) <...> > Yes, that's correct. The subprogram that goes the other way also has the > loops in the wrong order. Hello Jeff, I've pushed a patch on dev_1.8 branch: https://sourceforge.net/p/gnoga/code/ci/70be52accab63c4866aa8dfba32e759db744a134/ Is it correct for you? I've also included your reproducer, do you mind? Regards, Pascal. https://blady.pagesperso-orange.fr ___ Gnoga-list mailing list Gnoga-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gnoga-list
Re: [Gnoga-list] Errors in Gnoga.Gui.Element.Canvas.Context_2d
> Le 18 nov. 2023 à 21:26, J Carter a écrit : > > > I've upgraded Simple Components in dev_1.8 branch: > > https://sourceforge.net/p/gnoga/code/ci/dev_1.8/tree/ > > I've tested ok with GNAT FSF 13.2 from Alire. > > That compiles. Attached is a reproducer, data_error.adb, and corresponding > project file (edit the path to gnoga.gpr as needed). > > The Log call outputs > > 2023-11-18 21:03:10.59 : 4 3 > > (timestamp will vary), showing that the first dimension of a Pixel_Data_Type > is X/columns, and the 2nd is Y/rows, since the image is 4 wide and 3 high. > > The resulting PPM file contains > > P3 > 4 3 255 > 255 0 0 255 0 0 0 128 0 0 0 255 > 255 0 0 0 128 0 0 128 0 0 0 255 > 255 0 0 0 128 0 0 0 255 0 0 255 > > which is not what was drawn in the image. Hello Jeff, I've capture the javascript string: > Array.prototype.join.call (gnoga['g12'].data) < "255,0,0,255,255,0,0,255,255,0,0,255,255,0,0,255,0,128,0,254,0,128,0,255,0,128,0,255,0,128,0,254,0,0,252,252,0,0,255,255,0,0,255,255,0,0,252,252" The documentation says: ImageData.data Read only A Uint8ClampedArray representing a one-dimensional array containing the data in the RGBA order, with integer values between 0 and 255 (inclusive). The order goes by rows from the top-left pixel to the bottom-right. (https://developer.mozilla.org/en-US/docs/Web/API/ImageData) If my understanding is correct, this confirms your point, doesn't it? Gnoga String_To_Pixel_Data loops order isn't correct. Regards, Pascal. https://blady.pagesperso-orange.fr ___ Gnoga-list mailing list Gnoga-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gnoga-list
Re: [Gnoga-list] Errors in Gnoga.Gui.Element.Canvas.Context_2d
> Le 17 nov. 2023 à 15:03, J Carter a écrit : > > > But maybe the two same errors in both code cancel each other out. > > Yes, they would. > > > Could you please give a reproducer? > > Maybe not. I realized I hadn't pulled for a while, so I did a pull and now > "make all" has errors with the Simple Components. The first I saw was fixed > long ago, before GNAT 13 was released, IIRC: In > deps/simple_components/atomic-access/ada/gnat-sockets-server.adb, procedure > Do_Connect, 'Unchecked_Access needs to be changed to 'Unrestricted_Access. If > I fix that, then there are other errors that are not so obvious. It's as if > it's a much earlier version of the Simple Components. But that is another > issue. I've upgraded Simple Components in dev_1.8 branch: https://sourceforge.net/p/gnoga/code/ci/dev_1.8/tree/ I've tested ok with GNAT FSF 13.2 from Alire. Pascal. https://blady.pagesperso-orange.fr ___ Gnoga-list mailing list Gnoga-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gnoga-list
Re: [Gnoga-list] Errors in Gnoga.Gui.Element.Canvas.Context_2d
Hello Jeff, > Le 14 nov. 2023 à 18:35, Jeffrey R. Carter via Gnoga-list > a écrit : > > Comments ts based on the 1.7 branch. > > There appears to be an error in function String_To_Pixel_Data, based on the > string returned from function Data (Image_Data_Type) return String: the Y > loop needs to be the outer loop. Well, one chance out of two to be ... wrong. However, I recall having tested the Data procedure and function against Javascript in canva_test.adb. But maybe the two same errors in both code cancel each other out. Could you please give a reproducer? > In addition, the 4 function calls in the aggregate rely on the order of > evaluation, which is not specified by the language. While GNAT is unlikely to > change this, it's safer to assign the results of the calls to variables and > use them in the aggregate. > > Finally, the initialization of S has no effect. Yes it's typical coding style of David. I guess it isn't the only one in Gnoga. You know Ada better than me but I wonder what was David motivation. > Assuming that the string supplied to procedure Data (Image_Data_Type; String) > has the same format, then the change to the loops also applies to procedure > Data (Image_Data_Type; Pixel_Data_Type). Sure. Regards, Pascal. https://blady.pagesperso-orange.fr ___ Gnoga-list mailing list Gnoga-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gnoga-list
Re: [Gnoga-list] Replacing views results in a superposition instead
Hello Frank, > Le 4 oct. 2023 à 18:51, Frank Hrebabetzky a écrit : > > I found a way: removing explicitly the form of the view (with the checkbox on > it) did the job. For that to work I had to replace the text written with > view.Put_Line with an element of Text_Type placed on the form. Good to know. Doing some tests, that's the most efficient way with Gnoga ;-). > Nevertheless it seems strange to me that the elements on a form remain > visible after hiding the underlying view. Gnoga relies on the underlying HTML entities and Javascript code. Thus it may differ from one browser to the other. If you can inspect displayed page with your browser then you can watch Javascript instructions coming from Gnoga in Javascript console and look at HTML changes. Regards, Pascal. https://blady.pagesperso-orange.fr ___ Gnoga-list mailing list Gnoga-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gnoga-list
Re: [Gnoga-list] When to get a new Context_2D
> Le 20 sept. 2023 à 15:12, Jeffrey R. Carter via Gnoga-list > a écrit : > > If I have a canvas, I can get a context for it with Get_Drawing_Context_2D > and do lots of things with that context. But there are operations that change > the canvas, such as changing the width or height, that I would think would > invalidate an existing context and require getting a new context. Am I > correct about this? If so, is there a list of operations that require this? Hello Jeff, The underlying behavior is given by Javascript. As I'm not a specialist, I look at the documentation: https://developer.mozilla.org/en-US/docs/Web/API/HTMLCanvasElement/getContext It says: The HTMLCanvasElement.getContext() method returns a drawing context on the canvas, or null if the context identifier is not supported, or the canvas has already been set to a different context mode. Later calls to this method on the same canvas element, with the same contextTypeargument, will always return the same drawing context instance as was returned the first time the method was invoked. It is not possible to get a different drawing context object on a given canvas element. It seems that the context stay valid as it is unique. Regards, Pascal. https://blady.pagesperso-orange.fr ___ Gnoga-list mailing list Gnoga-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gnoga-list
Re: [Gnoga-list] Gnoga 2.1a configuration inconsistency
> Le 18 sept. 2023 à 11:25, Frank Hrebabetzky a écrit : > > The Gnoga installation instructions contain the line > > export GPR_PROJECT_PATH=/path/to/install/share/gpr:/path/to/install/lib/gnat > > After a default installation the last directory does not exist. The > directories/files in /path/to/install/lib/ are: > /components > /gnoga > /pragmarc > /uxstrings > /zanyblue > libsqlite3.a > but no /gnat. This is a due to gprbuild evolution. Legacy path for GPR installation was /path/to/install/lib/gnat. The new style path for GPR installation is /path/to/install/share/gpr. Depending your GNAT installation you may get one or the other thus the documentation mention both. I grant you it is certainly less and less the case. Regards, Pascal. https://blady.pagesperso-orange.fr ___ Gnoga-list mailing list Gnoga-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gnoga-list
Re: [Gnoga-list] v2 compatibility for end user
> Le 17 sept. 2023 à 16:05, Frank Hrebabetzky a écrit : > > Hi Pascal, > > Thanks to your advice, the error messages concerning my package net-main.adb > disappeared, but the ones for uxstrings remain without any change. Hi Frank, That's an old story with UTF-8 source code encodings and an issue with GPR actual options for GPR sub-project. Add "-gnat-W8" to your GPR GNAT project file even if your source files don't need. What is your Gnoga version? Last versions have a work around. Regards, Pascal. https://blady.pagesperso-orange.fr ___ Gnoga-list mailing list Gnoga-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gnoga-list
Re: [Gnoga-list] v2 compatibility for end user
> Le 10 sept. 2023 à 14:31, Frank Hrebabetzky a écrit :
>
> The thread "Attempt to make v2 backward compatible" addressed basically to
> Gnoga developers. As end user of Gnoga (and still in the learning phase) I
> would like to know how to treat the following compilation error:
>
> Compile
> [Ada] net-main.adb
> net-main.adb:18:12: error: no candidate interpretations match the actuals:
> net-main.adb:18:12: error: missing argument for parameter "Occurrence" in
> call to "Log" declared at gnoga.ads:113
> net-main.adb:18:60: error: expected private type
> "Ada.Exceptions.Exception_Occurrence"
> net-main.adb:18:60: error: found type "Standard.String"
> net-main.adb:18:60: error: ==> in call to "Log" at gnoga.ads:110
> net-main.adb:18:60: error: ==> in call to "Log" at gnoga.ads:107
> uxstrings.ads:93:81: error: strings are delimited by double quote character
> uxstrings.ads:93:81: error: expected type "Standard.Character"
> uxstrings.ads:93:81: error: found a string type
> uxstrings.ads:96:81: error: strings are delimited by double quote character
> uxstrings.ads:96:81: error: expected type "Standard.Character"
> uxstrings.ads:96:81: error: found a string type
> uxstrings.ads:108:92: error: strings are delimited by double quote character
> uxstrings.ads:108:92: error: expected type "Standard.Wide_Character"
> uxstrings.ads:108:92: error: found a string type
> uxstrings.ads:111:73: error: strings are delimited by double quote character
> uxstrings.ads:111:73: error: expected type "Standard.Wide_Character"
> uxstrings.ads:111:73: error: found a string type
> gprbuild: *** compilation phase failed
>
> The accused line 18 of net-main.adb is
>
> Gnoga.Log (Ada.Exceptions.Exception_Name (E) & " - " &
> Ada.Exceptions.Exception_Message (E));
>
> Compiler switches are
>
> package Compiler is
> for Default_Switches ("Ada") use ("-g", "-gnata", "-gnatq", "-gnatQ");
> end Compiler;
>
> First I thought it was an error in my application, but it compiles without
> any problem on another PC with Gnoga version 1. Then I thought I messed up
> the installation of Gnoga version 2.1a, but various reinstallations resulted
> in the same error. And when searching for help I got aware of the
> compatibility problem. So what should I do?
Hello Frank,
The main change between Gnoga V1 and V2 is string encoding improvement with
Unicode strings managed by UXStrings lib.
To ease this usage a subtype has been created in gnoga.ads:
https://sourceforge.net/p/gnoga/code/ci/dev_2.1/tree/src/gnoga.ads#l46
You may change your strings with this type, see example:
https://sourceforge.net/p/gnoga/code/ci/dev_2.1/tree/test/forms.adb#l17
Concerning your error you may use the dedicated Log procedure as here:
https://sourceforge.net/p/gnoga/code/ci/dev_2.1/tree/tutorial/tutorial-03/tutorial_03.adb#l60
or the one without message:
Gnoga.Log (E);
Regards, Pascal.
https://blady.pagesperso-orange.fr
___
Gnoga-list mailing list
Gnoga-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gnoga-list
Re: [Gnoga-list] Gnoga soon on Alire.
> Le 14 juil. 2022 à 19:01, Blady a écrit : > > 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). Here some news, Gnoga source codes have been mirrored on Github (https://github.com/Blady-Com/gnoga). Simple Components version has been upgraded. And thus the two main last stable versions of Gnoga are on Alire: % alr search gnoga --full NAME STATUS VERSION DESCRIPTION NOTES gnogaX 2.1.2gnoga - The GNU Omnificent GUI for Ada gnogaX 1.6.2gnoga - The GNU Omnificent GUI for Ada You can get them with: % alr get gnoga^1 or % alr get gnoga^2 At the moment, some external dependencies of Simple Components may put warnings on some platforms, for instance on macOS: warn:New solution is incomplete. warn:+♼ gnat 12.1.2 (new,installed,gnat_native) warn:+↪ libgnutls ^3.5.8 (new,external,indirect) warn:+ simple_components 4.62.0 (new) warn:+↪ unixodbc ^2.3 (new,external,indirect) warn: warn: Could not find a complete solution for gnoga=1.6.2 Build will fail unless externals are made available, do you want to continue? [Y] Yes [N] No (default is No) But unless you use Gnoga Secure, don't matter and say Yes. Then you can use it on the standard way e.g.: % make all For now, I haven't tested the Alire way: % alr with gnoga It is a small step, but it let you fetch Gnoga with Alire and use it in order to have more feedbacks. Feel free to report on the list ;-) Regards, Pascal. https://blady.pagesperso-orange.fr ___ Gnoga-list mailing list Gnoga-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gnoga-list
Re: [Gnoga-list] GIT master branch discussion.
> Le 6 août 2022 à 14:31, Développement - Sowebio a > écrit : > > Hi Pascal, >> Thus I've created a mirror repository on Github: >> >> https://github.com/Blady-Com/gnoga > For tickets, should we focus on Gihub on stay on SourceForge ? Hi Stéphane, Until I'll be able to set all Alire stuff, I prefer to keep SourceForge as current repository. Regards, Pascal. https://blady.pagesperso-orange.fr ___ Gnoga-list mailing list Gnoga-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gnoga-list
Re: [Gnoga-list] GIT master branch discussion.
> Le 7 avr. 2022 à 22:01, Blady via Gnoga-list > a écrit : > > Thanks a lot for all your answers. > > Thus I tried to set master for d) which got the majority. > > But SF GIT is enough twisted to reject the simple command: > > % git push --force origin master > Total 0 (delta 0), reused 0 (delta 0), pack-reused 0 > remote: error: denying non-fast-forward refs/heads/master (you should pull > first) > To https://git.code.sf.net/p/gnoga/code > ! [remote rejected] master -> master (non-fast-forward) > error: failed to push some refs to 'https://git.code.sf.net/p/gnoga/code' > > I tried more GIT commands without success but I'm not an experienced GIT user. > > Any GIT help will be appreciated. Hello all, Well, I looked SF documentation and found: https://sourceforge.net/p/forge/documentation/Git/#deleting-master-after-changing-default-branch But It seemed to me a bit dangerous and surely beyond by git knowledge. Thus I've created a mirror repository on Github: https://github.com/Blady-Com/gnoga The master is at the top. There are two development branches: dev_1.7 and dev_2.2. There are tags corresponding to stable releases. Feel free to report any discrepancy. Next steps: adding Alire support... 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] Gnoga soon on Alire.
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
Re: [Gnoga-list] GIT master branch discussion.
Thanks a lot for all your answers. Thus I tried to set master for d) which got the majority. But SF GIT is enough twisted to reject the simple command: % git push --force origin master Total 0 (delta 0), reused 0 (delta 0), pack-reused 0 remote: error: denying non-fast-forward refs/heads/master (you should pull first) To https://git.code.sf.net/p/gnoga/code ! [remote rejected] master -> master (non-fast-forward) error: failed to push some refs to 'https://git.code.sf.net/p/gnoga/code' I tried more GIT commands without success but I'm not an experienced GIT user. Any GIT help will be appreciated. Thanks, Pascal. > Le 27 mars 2022 à 03:16, David Botton a écrit : > > I vote d. That was how it was originally and what I think most expect. > > On Sun, Mar 20, 2022 at 7:16 AM Blady via Gnoga-list > wrote: > Hello, > > The master branch of the Gnoga GIT repo is stuck on version 1.2a for many > years. > Some users point out that, for instance: > "It is customary when using git to have the master branch point at the latest > stable branch. Is there any reason not to for gnoga?" (from Tama) > > Thus I propose some options: > > a) set master to the last stable V1 commit, that is V1.6a > b) set master to the last V1 commit, that is V1.7-alpha > c) set master to the last stable V2 commit, that is V2.1a > d) set master to the last V2 commit, that is V2.2-alpha > e) add branches named edge, stable... > f) do nothing > > My preference is for a). > > What is your feedback? > > 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] GIT master branch discussion.
Hello, The master branch of the Gnoga GIT repo is stuck on version 1.2a for many years. Some users point out that, for instance: "It is customary when using git to have the master branch point at the latest stable branch. Is there any reason not to for gnoga?" (from Tama) Thus I propose some options: a) set master to the last stable V1 commit, that is V1.6a b) set master to the last V1 commit, that is V1.7-alpha c) set master to the last stable V2 commit, that is V2.1a d) set master to the last V2 commit, that is V2.2-alpha e) add branches named edge, stable... f) do nothing My preference is for a). What is your feedback? Thanks, Pascal. https://blady.pagesperso-orange.fr ___ Gnoga-list mailing list Gnoga-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gnoga-list
Re: [Gnoga-list] 2.1a Not Backward Compatible
Hello Jeff,
> Le 13 mars 2022 à 12:42, J Carter via Gnoga-list
> a écrit :
>
> I note that Gnoga 2.1a is not backward compatible with 1.6a due to the
> introduction of UXStrings. I had hoped that this would only involve
> overloaded operations, and that those using String would continue to be
> available.
In January'21, the introduction in Gnoga 2.1 of support for
internationalization of programs might have actually led to backward
compatibility issues, the intend was clearly to reduce them as possible.
Thus, the compatibility with Gnoga 2.1 is not straightforward though UXStrings
API were inspired from Ada.Strings.Unbounded in order to minimize adaptation
work from existing Ada source codes.
I've adapted Gnoga demos, tutorials and tests source code with some specific
lines added to ease the adaptation:
+ use all type Gnoga.String;
+
+ subtype String is Gnoga.String;
Then you will change all _String types to only String.
Some Image facilities are provided:
- Game_log ("Swapping: (" & c1.x'Img & c1.y'Img & ") and (" & c2.x'Img &
c2.y'Img & ")");
+ Game_log ("Swapping: (" & Image (c1.x) & Image (c1.y) & ") and (" &
Image (c2.x) & Image (c2.y) & ")");
or else create you own:
+ function Image is new UXStrings.Conversions.Scalar_Image (Match_kind);
Some conversions are provided:
-return +Item.Director;
+return From_UTF_8 (+Item.Director);
and
-Item.Director.Assign (From => Value);
+Item.Director.Assign (From => To_UTF_8 (Value));
See for instance Chattanooga adaptation:
https://sourceforge.net/p/gnoga/code/ci/d56722a45bbc370635a5fb31996cb68528d9e9dd/tree/demo/chattanooga/chattanooga.ads?barediff=524b530a568a185373790abcdc06d6101fd4
With other Gnoga demos changes:
https://sourceforge.net/p/gnoga/code/ci/d56722a45bbc370635a5fb31996cb68528d9e9dd/#diff-10
> In addition to littering my code with conversions to UXString, I would have
> to change any sources I have that use the upper half of Character to UTF-8
> encoding, as the spec of UXStrings uses non-ASCII characters in UTF-8
> encoding, GNAT's source-based model means that specs are read every time
> something that uses the pkg is compiled, so any compilation against Gnoga
> must use UTF-8 encoding. This seems like excess effort for no gain, so I
> won't be making the transition immediately.
Conversion from and to UXStrings are limited to the outer world as files or
databases but it was the same before with conversions from and to Ada Latin-1
strings.
There is no more conversion between UXStrings and data received or sent to your
HTML browser.
In Gnoga 1.x conversions are actually present from Ada Latin-1 to UTF-8
Javascript and vice versa.
The goal was to open the ability to use characters that are not included in
Latin-1, that is not possible at no cost.
For instance, with Gnoga 1.x you are not able to process correctly a user
browser entry: "Price 10 €".
The Euro sign is replaced by a joker character. With Gnoga 2.x it is processed
correctly.
> However, it appears that 2.1a has resolved the recompilation problem that
> plagued earlier versions. What was the culprit and its fix? I would like to
> see the fix applied back to earlier versions if possible.
The fix from Gauthier has been applied on 1.7:
https://sourceforge.net/p/gnoga/code/ci/c12bff8262ad6c0e88e9923691e59bb49e5a34e3/
HTH, 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] [ANN] Gnoga version 2.1a and 2.2-alpha.
Hello, Gnoga version 2.1a has been release on SF GIT: https://sourceforge.net/p/gnoga/code/ci/dev_2.1/tree/ and on SF files as zipped source code: https://sourceforge.net/projects/gnoga/files/ See HISTORY for details: https://sourceforge.net/p/gnoga/code/ci/dev_2.1/tree/HISTORY Then new branch dev_2.2 has been created to collect new Gnoga 2.2-alpha developments. 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
Re: [Gnoga-list] Selection_Type Value and Apostrophes
> Le 15 déc. 2021 à 11:50, Jeffrey R. Carter via Gnoga-list > a écrit : > > These work for my situation, thanks. > > I'm a bit surprised no unquote operation is needed. Gnoga server sent always data encapsulated in a JS script which is interpreted by the JS boot code load in your browser at beginning of connection. On the other way, the data sent by the boot code is just parsed by Ada code not interpreted ;-) For instance keyboard event parsing: https://sourceforge.net/p/gnoga/code/ci/dev_1.7/tree/src/gnoga-gui-base.adb#l156 Regards, Pascal. https://blady.pagesperso-orange.fr ___ Gnoga-list mailing list Gnoga-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gnoga-list
Re: [Gnoga-list] Selection_Type Value and Apostrophes
> Le 8 déc. 2021 à 23:24, Jeffrey R. Carter via Gnoga-list > a écrit : > > I encountered this storing file names. I suppose I could add my own encoding > for apostrophes before adding, & decoding when retrieving. Presumably that > would be needed for quotation marks as well. Hello Jeff, I've pushed some modifications on SF (GNOGA dev_1.7): https://sourceforge.net/p/gnoga/code/ci/82e37a37853c92188c4df3a979ac9c5586db0f14/ I haven't tested them extensively but made some review on the code. Please keep me informed if it solves your issue without side effect. I've also taken the opportunity to suppress PragmARC from GNOGA as you proposed previously. Regards, Pascal. https://blady.pagesperso-orange.fr ___ Gnoga-list mailing list Gnoga-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gnoga-list
Re: [Gnoga-list] Selection_Type Value and Apostrophes
> Le 6 déc. 2021 à 06:57, Jeffrey R. Carter via Gnoga-list > a écrit : > > Probably it's line 1544, since I used Add_Option. Hello Jeff, Yes and also many other locations are concerned. Strings have to be parsed against quotes in particular cases of HTML attributes but also for Javascript code. Instead of cumulating string parsings which will decrease performances, I will try to target only what is necessary. In the meantime, as a workaround, if your source code is appropriate with literal strings for instance, you may replace apostrophes with the HTML equivalent . Best, Pascal. https://blady.pagesperso-orange.fr ___ Gnoga-list mailing list Gnoga-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gnoga-list
Re: [Gnoga-list] Selection_Type Value and Apostrophes
> Le 4 nov. 2021 à 14:07, J Carter via Gnoga-list
> a écrit :
>
> Somewhere in the intersection of Gnoga 1.6, GNAT 11.2, and Firefox 94.0 on
> Xubuntu 20.10 I have encountered this "feature". If the Value supplied for an
> option of a Selection_Type contains an apostrophe ('), the Value function for
> that option discards the apostrophe and all characters after it. I'm not sure
> if this is expected behavior.
Hello Jeff,
I can reproduce.
The offending line is here:
https://sourceforge.net/p/gnoga/code/ci/dev_1.6/tree/src/gnoga-gui-element-form.adb#l1599
Escaping quotes at multilevel of Javascript evaluation strings is a nightmare
;-)
I'll look for a global fix as many locations are concerned.
Best, Pascal.
https://blady.pagesperso-orange.fr
___
Gnoga-list mailing list
Gnoga-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gnoga-list
Re: [Gnoga-list] Modifying a Check Box
> Le 30 oct. 2021 à 00:15, Wayne Bullaughey via Gnoga-list > a écrit : > > I have case when the user checks one check box the code will set a different > check box and disable that one. > > In my application the check box that gets set does not update to show that it > has been checked and does not gray out to show it has been disabled. When the > disabled check box is clicked it redraws showing it is checked and disabled. > > How can I force the check box to be redrawn? Hello Wayne, The drawing is on the browser side. Each change should be visible. Could you share a piece of code reproducing your case? Regards, Pascal. https://blady.pagesperso-orange.fr ___ Gnoga-list mailing list Gnoga-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gnoga-list
Re: [Gnoga-list] justGage
> Le 26 oct. 2021 à 11:50, Stéphane LOS a écrit : > > Hello there, > > justGage in one of the libraries used by the Node-RED Dashboard : > https://flows.nodered.org/node/node-red-dashboard > https://toorshia.github.io/justgage/ > > It looks pretty simple and it should not be too difficult to create a Gnoga > plugin but I've looked the other plugins and I miss some guidelines on the > low level mechanisms of Gnoga. > > I won't give up any soon but a little help would be nice. > > I'm looking also on adding charting library. justGage is my first attempt. Hello Stéphane, That's nice plugin outcome ;-) There isn't any standalone guidelines but when writing Pixi plugin I was inspired by those written by David. When creating the PIXI plugin I went through the following steps: First I wrote the complete specification at once, for instance with sprites: https://sourceforge.net/p/gnoga/code/ci/dev_1.6/tree/components/pixi/src/gnoga-gui-plugin-pixi-sprite.ads The Load_PIXI procedure is used to load the needed stuff for the Javascript part of the plugin. https://sourceforge.net/p/gnoga/code/ci/dev_1.6/tree/components/pixi/src/gnoga-gui-plugin-pixi.ads#l53 The chosen type of your plugin object may be: - Gnoga.Gui.Base.Base_Type - Gnoga.Gui.Element.Element_Type - Gnoga.Gui.View.View_Type It depends on which set of API you want to inherit to write the implementation part of the plugin. I chose Gnoga.Gui.Element.Element_Type: https://sourceforge.net/p/gnoga/code/ci/dev_1.6/tree/components/pixi/src/gnoga-gui-plugin-pixi.ads#l60 but it might be Gnoga.Gui.Base.Base_Type: https://sourceforge.net/p/gnoga/code/ci/dev_1.6/tree/components/pixi/src/gnoga-gui-plugin-pixi.ads#l64 Then comes the creation procedure of the GUI object.https://sourceforge.net/p/gnoga/code/ci/dev_1.6/tree/components/pixi/src/gnoga-gui-plugin-pixi-sprite.ads#l70 All specific API subroutines which follow are split in properties: https://sourceforge.net/p/gnoga/code/ci/dev_1.6/tree/components/pixi/src/gnoga-gui-plugin-pixi-sprite.ads#l70 and methods: https://sourceforge.net/p/gnoga/code/ci/dev_1.6/tree/components/pixi/src/gnoga-gui-plugin-pixi-sprite.ads#l264 Let be inspired by your Javascript API: https://github.com/toorshia/justgage#methods On the implementation side: The Load_PIXI procedure is implemented with the plugin script. https://sourceforge.net/p/gnoga/code/ci/dev_1.6/tree/components/pixi/src/gnoga-gui-plugin-pixi.adb#l46 The Create procedure is somewhat special : - set the object ID with a new one https://sourceforge.net/p/gnoga/code/ci/dev_1.6/tree/components/pixi/src/gnoga-gui-plugin-pixi.adb#l68 - set the connection ID to the window ID (seem not needed with next step) https://sourceforge.net/p/gnoga/code/ci/dev_1.6/tree/components/pixi/src/gnoga-gui-plugin-pixi.adb#l69 - attach the object to message system https://sourceforge.net/p/gnoga/code/ci/dev_1.6/tree/components/pixi/src/gnoga-gui-plugin-pixi.adb#l70 - initialize the object on Javascript side https://sourceforge.net/p/gnoga/code/ci/dev_1.6/tree/components/pixi/src/gnoga-gui-plugin-pixi.adb#l72 - fire the message child added to the parent https://sourceforge.net/p/gnoga/code/ci/dev_1.6/tree/components/pixi/src/gnoga-gui-plugin-pixi.adb#l80 Then implements your API using the ones of Gnoga. If you want to use the message system, ask me. HTH, Pascal. https://blady.pagesperso-orange.fr ___ Gnoga-list mailing list Gnoga-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gnoga-list
Re: [Gnoga-list] [ANN] Gnoga version 1.6a and 2.1-beta.
> Le 25 mai 2021 à 21:27, Blady via Gnoga-list > a écrit : > >> >> Le 22 mai 2021 à 10:18, Joakim Dahlgren Strandberg a écrit >> : >> >> 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 > > Hello Joakim, good catch. > > Notice that executing gprbuild from Gnoga root folder is ok: > % gprbuild ./ssl/gnoga_secure.gpr > (current path is by default in gprbuild project search path list) > > But you're right, it's better to change. > I'll look for all occurrences and fix them. Hello Joakim, These occurrences have been fixed in last commit : https://sourceforge.net/p/gnoga/code/ci/6fe2723b323f14c250390e3be5ec0162c265932f/ Regards, Pascal. https://blady.pagesperso-orange.fr ___ Gnoga-list mailing list Gnoga-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gnoga-list
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 := null; > Connection_Type : Gnoga_Connection_Type := HTTP; > Connection_Path : Ada.Strings.Unbounded.Unbounded_String; > FS : Ada.Streams.Stream_IO.File_Type; > Input_Overflow : String_Buffer; > Buffer : String_Buffer; > Finalized : Boolean := False; > Text: aliased Strings_Edit.Streams.String_Stream (500); > end record; > > I am working on a fix for this, the simplest would be to increase the > discriminant to, say, 4096… but this merely moves the constraint to 4KB, > instead of memory arbitrary [arguments may be made for both], so I will > likely experiment on it to see if I can get a less-limited solution. Hello Joey, Well, few years ago, I came across these two issues when I had to dig in POST mechanism. I agree that this current way is not very convenient. The value 500 should be a constant in gnoga-server-connection-common.ads. Indeed, though GET and POST are supported, Gnoga is designed to play rather with events. What is your use case? Regards, Pascal. https://blady.pagesperso-orange.fr ___ Gnoga-list mailing list Gnoga-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gnoga-list
Re: [Gnoga-list] [ANN] Gnoga version 1.6a and 2.1-beta.
> Le 22 mai 2021 à 10:18, Joakim Dahlgren Strandberg a écrit : > > 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 Hello Joakim, good catch. Notice that executing gprbuild from Gnoga root folder is ok: % gprbuild ./ssl/gnoga_secure.gpr (current path is by default in gprbuild project search path list) But you're right, it's better to change. I'll look for all occurrences and fix them. Thanks for your report, Pascal. https://blady.pagesperso-orange.fr ___ Gnoga-list mailing list Gnoga-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gnoga-list
Re: [Gnoga-list] Rebuilding from scratch
> Le 10 mai 2021 à 18:38, Joakim Dahlgren Strandberg a écrit : > > 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? Hello, Indeed there are two ways of using Gnoga. On one hand, as Joakim said, add the path of gnoga.gpr in your GPR file and build all together Gnoga and your program. See more details on §4: https://sourceforge.net/p/gnoga/code/ci/dev_1.6/tree/INSTALL On the other hand, install Gnoga with "make install" and add the path of the installed gnoga.gpr in your GPR file and build your program. Tips: "make help" will give your actual INSTALL folder at line PREFIX. See more details on §1: https://sourceforge.net/p/gnoga/code/ci/dev_1.6/tree/INSTALL This latter way needs that you use the same compiler for installing Gnoga and your program. HTH, 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] [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] Gnoga V1.6 release date?
Hello, Since Gnoga V1.6-beta announcement (https://sourceforge.net/p/gnoga/mailman/message/37121840/) I haven't receive any Windows or Linux test report :-( On my side testing with macOS, i'm facing two tough issues: 1) PROGRAM_ERROR : accessibility check failed, see on list (https://sourceforge.net/p/gnoga/mailman/message/37090637/). I've just push a rough fix that suppress the PROGRAM-ERROR. However I'm not really sure it is the correct fix: https://sourceforge.net/p/gnoga/code/ci/7aeba1a99172352534d3398f84d7ebf9ee1ad155/ Give me your feedback. 2) On_Connect_Submit: raised PROGRAM_ERROR : s-taprob.adb:182 explicit raise 2021-02-10 20:46:09.30 : On_Connect_Submit: raised PROGRAM_ERROR : s-taprob.adb:182 explicit raise Call stack traceback locations: system__tasking__protected_objects__lock_read_only (in chattanooga) + 182 chattanooga__db__control__existsP (in chattanooga) (chattanooga-db.adb:92) chattanooga__db__exists (in chattanooga) (chattanooga-db.adb:37) chattanooga__ui__on_connect_submit (in chattanooga) (chattanooga-ui.adb:205) gnoga__gui__base__fire_on_submit (in chattanooga) (gnoga-gui-base.adb:1042) gnoga__gui__base__on_message (in chattanooga) (gnoga-gui-base.adb:2006) gnoga__server__connection__dispatch_task_typeTB (in chattanooga) (gnoga-server-connection.adb:1812) system__tasking__stages__task_wrapper (in chattanooga) + 473 It was working well with GNAT 2019. Jeff said: "So the task making the callback is running at Default_Priority, the PO has a much higher ceiling priority, and you're getting an exception due to a check for a ceiling violation. That's very odd indeed. If so, then I would think you should report this to AdaCore." Unfortunately, I couldn't be able to make a simple reproducer in order to report to AdaCore. Any ideas are welcome. The V1.6 changes are: - Gnoga: adaptation to PIXI 5.3.0. - Gnoga: adaptation to GNAT Community 2020. - Upgrade to PIXI 5.3.0. - Upgrade to ACE 1.4.12. - Upgrade to Simple Components 4.50. - Update Jeff Carter's Pragmarc from Github. - Gnoga: adaptation to GNAT Community 2020. - JQuery Javascript source upgrade version 3.5.0. - Add experimental package UXStrings (see readme). - Demo: add a simple localization tool (Localize) to help edition of localization files. - Form: add additional support for file input with multiple files. Change some API. - Add support for files upload (implementing Javascript FileReader). - Form: add support for file and tel field types. Fix UTF8 character conversions in form names. Is this version reliable enough? Tell on the list if you agree to release 1.6 as it is. Thanks, Pascal. https://blady.pagesperso-orange.fr ___ Gnoga-list mailing list Gnoga-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gnoga-list
Re: [Gnoga-list] Referencing dynamically created items by ID.
> Le 9 févr. 2021 à 16:12, Joey Fish a écrit : > > Ok, so I’m having a little problem getting information from a > dynamically-created element for a reporting-system I am building. – It works > by having a draggable DIV containing elements/values the user wishes to > report, dragging it to a specified area on the form, and then populating the > form with elements set to the appropriate values. – This works well and > straightforward for the case where the data is statically known, because I > can put that element in a record-field, but not so much when the elements are > generated via dynamic methods (INI-file in this particular case).* > > HTML elements in play: > (1) The FORM element; > (2) The DIV containing the elements of a report; > (3) The SELECTs populated by the INI-file’s data; > (4) The DIV containing the FORM elements to submit. > Note: the DIV in #2 is not part of the FORM, but rather a template the user > completes and then is processed by the drag-event handler to add > form-elements to the form. > > So, what is the best way to obtain a Gnoga element from a given ID? > * I could initialize a vector to hold the elements when they are generated, > but it seems like there should be a method to query the view for a > child-element of given ID. Hello Joey, See Tips #11 on Gnoga wiki: https://sourceforge.net/p/gnoga/wiki/Gnoga-Home • How do I get a hold on a child element, on the gnoga side, knowing its ID? My_Button.Attach_Using_Parent (View, ID => "my_button"); See a simple example: https://sourceforge.net/p/gnoga/code/ci/dev_1.5/tree/tutorial/tutorial-04/tutorial_04.adb#l123 A more complex example: https://sourceforge.net/p/gnoga/code/ci/dev_1.5/tree/demo/adablog/adablog-view.adb#l44 https://sourceforge.net/p/gnoga/code/ci/dev_1.5/tree/demo/adablog/adablog-controller.adb#l38 HTH, 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] Gnoga 2.1 with UXStrings.
Hello, I wish you and your family the best for 2021. UXStrings library offers a private String type supporting Unicode and dynamic length, see: https://github.com/Blady-Com/UXStrings UXStrings library has been developed for applications requiring internationalization management as those written for the web with Gnoga. UXStrings is now included in Gnoga 2.1-alpha. Here are the instructions to get Gnoga 2.1: % git clone https://git.code.sf.net/p/gnoga/code gnoga-code % cd gnoga-code % git checkout dev_2.1 Here are the instructions to build converted test programs: % make deps basic_components % make tests-forms % make tests-pixi_sprite_test % make localize Lets' give a try with forms test program: % ./bin/forms Gnoga:2.1-alpha Application root :/opt/gnoga-code-2.x/ Executable at:/opt/gnoga-code-2.x/bin/ HTML root:/opt/gnoga-code-2.x/html/ Upload directory :/opt/gnoga-code-2.x/upload/ Templates root :/opt/gnoga-code-2.x/templates/ /js at :/opt/gnoga-code-2.x/js/ /css at :/opt/gnoga-code-2.x/css/ /img at :/opt/gnoga-code-2.x/img/ Boot file:debug.html HTTP listen on ::8080 Multi-connect application. Press Ctrl-C to close server. 2021-01-03 21:17:40.97 : HTTP Server Started Type some text with Unicode characters: Clic on "send to demo via get": All unicode characters are well processed, see the converted code: https://sourceforge.net/p/gnoga/code/ci/1bdbfeb599e4b36ecfae2db1fc4bbe7d113e9302/ A quick way is chosen in masking Standard.String type with a subtype declaration: 9. with UXStrings; 10. 11. procedure Forms is 12.use Gnoga; 13.use Gnoga.Types; 14.use Gnoga.Gui; 15.use Gnoga.Gui.Element; 16.use UXStrings; 17. 18.subtype String is UXString; Starting from scratch, UXStrings is used as any other package, see test programs: https://sourceforge.net/p/gnoga/code/ci/dev_2.1/tree/deps/uxstrings/tests/test_uxstrings.adb https://sourceforge.net/p/gnoga/code/ci/dev_2.1/tree/deps/uxstrings/tests/test_uxstrings_text_io.adb There are some limitations: • not thread safe • single character assignment is not implemented • only few API are implemented Tests have been run on macOS with GNAT Community 2020. Next considered steps: 1) Convert the remaining Gnoga demos and test programs to UXStrings 2) Implement the remaining UXStrings API 3) Add more API to UXStrings 4) Experience UXStrings with other programs These steps are equivalent priority, don't hesitate to send feedback about what seems more judicious in your opinion. Enjoy Gnoga, 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] V1.6-beta release.
Hello, Version V1.6-beta has been released on SF GIT branch dev_1.6: https://sourceforge.net/p/gnoga/code/ci/dev_1.6/tree/ V1.6 will no more change for new features. See HISTORY for features added. V1.6 has been tested (demos, tests, tutorials) with GNAT Community 2020 on macOS 10.15 with Safari 14. Volunteers are welcome to test it further on their own configuration. Some testing on Windows and Linux configuration will be appreciated. Just get last commit on https://sourceforge.net/p/gnoga, do: $ git clone https://git.code.sf.net/p/gnoga/code gnoga-code $ git checkout dev_1.6 $ make all and for courageous: $ make tests then: $ cd bin and test. Feel free to report detailed issues on this list or create tickets on SF. 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] PROGRAM_ERROR : accessibility check failed.
Hello, Thanks to Tama reporting in ticket 47 (https://sourceforge.net/p/gnoga/tickets/47/) a PROGRAM_ERROR due accessibility check failed is issued. I can reproduce it with GNAT Community 2020. Fixing it with a workaround, an other PROGRAM_ERROR is issued later: 2020-08-21 18:59:47.13 : raised PROGRAM_ERROR : gnoga-gui-view-docker.adb:117 accessibility check failed tutorial_09__on_connect.5551 (in tutorial_09) (tutorial_09.adb:94) See: https://sourceforge.net/p/gnoga/code/ci/dev_1.6/tree/tutorial/tutorial-09/tutorial_09.adb#l94 It wasn't the case with GNAT Community 2019. I can't see what could be detected wrong now and not before. Any idea? 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] Several components upgraded.
Hello, Gnoga 1.6-alpha has been upgraded with: - Simple Components 4.50 - PragmARC lastest - ACE 1.4.12 - PIXI 5.3.0 PIXI V5 brings new Application object with native WebGL. Any existing HTLM canvas has to be bound to the Application object instead of former render object. Corresponding sub-programs have been created and may require some reworks on existing code, see PIXI test program: https://sourceforge.net/p/gnoga/code/ci/dev_1.6/tree/test/pixi_sprite_test.adb#l121 Feel free to report feedback on the list or to open ticket. 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] RFC UXStrings package.
Hello,
Gnoga internal character strings implementation is based on both Ada types
String and Unbounded_String. The native Ada String encoding is Latin-1 whereas
transactions with the Javascript part are in UTF-8 encoding.
Some drawbacks come up, for instance, with internationalization of programs
(see Localize Gnoga demo
https://sourceforge.net/p/gnoga/code/ci/dev_1.6/tree/demo/localize):
• several conversions between String and Unbounded_String objects
• it isn't usable out of Latin-1 character set, characters out of
Latin-1 set are blanked
• continuous conversions between Latin-1 and UTF-8, each sent and
received transaction between Ada and Javascript parts
Two ways of improvement: native dynamic length handling and Unicode support.
First possibility is using UTF-8 as internal implementation in Unbounded_String
objects. The simplest way but Gnoga uses many times character indexes to parse
Javascript messages that is not easy to achieved with UTF-8 which may have
several lengths to represent one character. String parsing will be time
consuming. Some combinations may lead to incorrect UTF-8 representation.
Second possibility is to use Unbounded_Wide_String or
Unbounded_Wide_Wide_String. Using Unbounded_Wide_String is quite being in the
middle of the river might as well use Unbounded_Wide_Wide_String. In this
latter case the memory penalty is heavy for only few accentuated character
occurrences. So back to Unbounded_Wide_String but you'll miss the so essential
emojis ;-)
Third possibility is to make no choice between Latin-1, Wide and Wide_Wide
characters. The object shall adapt its inner implementation to the actual
content. For instance with English language the most often use case will be
Latin-1 inner implementation, for French language the most often will be
Latin-1 with some exceptions with BMP (Unicode Basic Multilingual Plane)
implementation such as in "cœur", for Greek language the most often will be BMP
implementation. The programer won't make any representation choice when for
example receiving UTF-8 messages:
S2 : UXString;
...
S2 := "Received: " & From_UTF8 (Message);
Automatically S2 will adapt its inner representation to the received characters.
Package named UXStrings (Unicode Extended String) is containing :
(see
https://sourceforge.net/p/gnoga/code/ci/dev_1.6/tree/deps/uxstrings/src/uxstrings.ads)
The first part contains renaming statements of Ada types. Ada String type is
structurally an array of Latin-1 characters thus is renamed as
Latin_1_Character_Array. And so on.
The second part defines the USXString type as a tagged private type which has
got aspects such as Constant_Indexing, Variable_Indexing and Iterable, so we
can write:
S1, S2, S3 : UXString;
C : Character;
WC : Wide_Character;
WWC: Wide_Wide_Character;
...
C := S1 (3);
WC := S1 (2);
WWC := S1 (1);
S1 (3) := WWC;
S1 (2) := WC;
S1 (1) := C;
for I in S3 loop
C := S3 (I);
WC := S3 (I);
WWC := S3 (I);
Put_Line (Character'pos (C)'img & Wide_Character'pos (WC)'img &
Wide_Wide_Character'pos (WWC)'img);
end loop;
The third part defines conversion functions between UXString and various
encoding such as Latin-1, BMP (USC-2), Unicode (USC-4), UTF-8 or UTF-16, so we
can write:
S1 := From_Latin_1 ("blah blah");
S2 := From_BMP ("une soirée passée à étudier la physique ω=Δθ/Δt...");
S3 := From_Unicode ("une soirée passée à étudier les mathématiques ℕ⊂핂...");
Send (To_UTF_8 (S1) & To_UTF_8 (S3));
The fourth part defines various API coming from Unbounded_String such as
Append, "&", Slice, "=", Index and so on.
The private and implementation parts are not yet defined. One idea is to use
the XStrings from GNATColl.
(see
https://github.com/AdaCore/gnatcoll-core/blob/master/src/gnatcoll-strings_impl.ads)
Feel free to send feedback about UXStrings specification source code on Gnoga
mailing list.
(https://sourceforge.net/p/gnoga/code/ci/dev_1.6/tree/deps/uxstrings/src/uxstrings.ads)
Thanks, Pascal.
https://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
> Le 1 oct. 2019 à 10:40, Henrik Härkönen a écrit :
> Hey!
> Thanks Joakim for the super-quick reply! :)
>
> I'll take a look at the forms demo, thanks!
>
> I think the full page reload is just fine for now. Maybe if I get the other
> stuff to work as the way I intended, I might be interested in more fancy
> operation like ajax for it.
>
> -Henrik
>
> On Tue, Oct 1, 2019 at 11:10 AM Joakim Dahlgren Strandberg
> wrote:
> 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.
Hello,
I've added in Gnoga the support of Javascript FileReader API, see:
https://sourceforge.net/p/gnoga/code/ci/dev_1.6/tree/src/gnoga-client-files.ads
I've added also a short example, it uploads the chosen file and puts its
content in a text box, see:
https://sourceforge.net/p/gnoga/code/ci/dev_1.6/tree/test/files_ops.adb
This version is in alpha status, thus it may change.
All combination haven't been fully tested.
Let me know if it is suitable for your needs.
Moreover, feel free to send comments and change proposals.
Regards, Pascal.
https://blady.pagesperso-orange.fr
___
Gnoga-list mailing list
Gnoga-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gnoga-list
