Unrelated thing to the previous bugs:
In Gnoga.Gui.Elements.Form, there is a function for turning Autocomplete
off and on. When I tried to disable autocomplete on a Text input type, it
didn't work. Inspecting the DOM showed that it set:
autocomplete="false"
when (at least for that input type) it should be
autocomplete="off"
I used the Property procedure in Gnoga.Gui.Base to work around it (setting
the field manually).
The rest of my responses are below:
On Thu, May 3, 2018 at 5:03 PM, Pascal via Gnoga-list <
gnoga-list@lists.sourceforge.net> wrote:
> Hello Jeremiah,
>
>
> > Le 3 mai 2018 à 02:35, Jeremiah Breeden <jeremiah.bree...@gmail.com> a
> écrit :
> >
> > Thanks, that got the build process going. Ran into the following
> problems:
> >
> > 1. building Zanyblue places random "build" folders in my directory
> structure outside of my gnoga envrionment. I originally thought this was a
> windows only issue, but today I was building it for a variant of Ubuntu
> 16.04 and it did the same there if my gnoga directory was far enough away
> from root locked folders. To be clear if I have:
> >
> > /d/Program_Files/mingw64/home/Jere/gnoga-code/
> >
> > and I build zany blue, I get phantom "build" directories in the
> following locations:
> >
> > /d/build
> > /d/Program_Files/build
> > /d/Program_Files/mingw64/home/build
> >
> > I get the same results in my Ubuntu 16.04 variant OS. I noticed in the
> main Makefile that the path ../../../build is passed to the zanyblue
> makefile. I wonder if it is using it incorrectly in places?
>
> Here is what I got (macOS):
> cd deps/zanyblue/src && "/Applications/Xcode.app/
> Contents/Developer/usr/bin/make" INSTALL_DIR=../../../build
> APPDIRS="zbmcompile zbinfo" install
> gprinstall -f -p --prefix=../../../build -p -XOS=unix -XTYPE=static
> -XBUILD=Debug -aP../src zanyblue.gpr
> Install project ZanyBlue
> gprinstall -f -p --prefix=../../../build -p -XOS=unix -XTYPE=static
> -XBUILD=Debug -aP../src --mode=usage zbmcompile/zbmcompile.gpr
> Install project zbmcompile
> gprinstall -f -p --prefix=../../../build -p -XOS=unix -XTYPE=static
> -XBUILD=Debug -aP../src --mode=usage zbinfo/zbinfo.gpr
> Install project zbinfo
>
> What do you get on your side?
>
> I suspect an issue with gprbuild which some versions don't handle relative
> path correctly.
> Here is a patch:
>
> diff --git a/Makefile b/Makefile
> index bf6a37c7..5e166458 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -145,7 +145,7 @@ sqlite3: lib/libsqlite3.a
> # Zanyblue with DEBUG on
> zanyblue:
> - cd deps/zanyblue/src && "$(MAKE)" BUILD=Debug
> APPDIRS="zbmcompile zbinfo"
> - - cd deps/zanyblue/src && "$(MAKE)" INSTALL_DIR=../../../build
> APPDIRS="zbmcompile zbinfo" install
> + - cd deps/zanyblue/src && "$(MAKE)" INSTALL_DIR="$(CWD)/build"
> APPDIRS="zbmcompile zbinfo" install
>
> pragmarc:
> $(BUILDER) -P deps/PragmARC/lib_pragmarc.gpr
>
>
> Does it work better?
>
The patch stops the phantom "build" directories. Thank you!
I did notice it was failing to build zbcompile on my side (while your side
compiled it correctly.
My new output is:
$ make zanyblue
cd deps/zanyblue/src && "make" BUILD=Debug APPDIRS="zbmcompile zbinfo"
make[1]: Entering directory
'/home/Jere/gnoga-code-2018_05_01/deps/zanyblue/src'
gprbuild -p -XOS=Windows_NT -XTYPE=static -XBUILD=Debug -aP../src -P
zanyblue.gpr
"libzanyblue.a" up to date
make -C zbmcompile
make[2]: Entering directory
'/home/Jere/gnoga-code-2018_05_01/deps/zanyblue/src/zbmcompile'
gprbuild -p -p -XOS=Windows_NT -XTYPE=static -XBUILD=Debug -aP../../src -P
zbmcompile
gprbuild: "zbmcompile.exe" up to date
make[2]: Leaving directory
'/home/Jere/gnoga-code-2018_05_01/deps/zanyblue/src/zbmcompile'
make -C zbinfo
make[2]: Entering directory
'/home/Jere/gnoga-code-2018_05_01/deps/zanyblue/src/zbinfo'
gprbuild -p -p -XOS=Windows_NT -XTYPE=static -XBUILD=Debug -aP../../src -P
zbinfo
gprbuild: "zbinfo.exe" up to date
make[2]: Leaving directory
'/home/Jere/gnoga-code-2018_05_01/deps/zanyblue/src/zbinfo'
make[1]: Leaving directory
'/home/Jere/gnoga-code-2018_05_01/deps/zanyblue/src'
cd deps/zanyblue/src && "make"
INSTALL_DIR=/home/Jere/gnoga-code-2018_05_01/build APPDIRS="zbmcompile
zbinfo" install
make[1]: Entering directory
'/home/Jere/gnoga-code-2018_05_01/deps/zanyblue/src'
gprinstall -f -p --prefix=/home/Jere/gnoga-code-2018_05_01/build -p
-XOS=Windows_NT -XTYPE=static -XBUILD=Debug -aP../src zanyblue.gpr
Install project ZanyBlue
gprinstall -f -p --prefix=/home/Jere/gnoga-code-2018_05_01/build -p
-XOS=Windows_NT -XTYPE=static -XBUILD=Debug -aP../src --mode=usage
zbmcompile/zbmcompile.gpr
Install project zbmcompile
file
D:\Program_Files\msys64\home\Jere\gnoga-code-2018_05_01\deps\zanyblue\bin\zbmcompile
does not exist, build may not be complete
make[1]: *** [../src/mkfile/install.mk:69: install-zb] Error 1
make[1]: Leaving directory
'/home/Jere/gnoga-code-2018_05_01/deps/zanyblue/src'
make: [Makefile:148: zanyblue] Error 2 (ignored)
I looked and zbmcompile.exe is the correct location, so I don't know why it
says it doesn't exist unless it can't tell due to the lack of ".exe" in the
build setup somewhere?
> >
> > 2. Some potential bugs:
> > components/pixi/src/gnoga-gui-plugin-pixi-sprite.adb
> > lines 86 and 876 call Sprite.Loop_Times() but in Ada you cannot use the
> object.operation notation unless operation is a primitive operation. Since
> both the declaration and the definition are in the body file (.adb) it
> cannot be a primitive operation and thus the call is illegal. Ironically,
> recent versions of GNAT compile it fine, but when I use 5.4 on my Ubuntu
> box, it flags it as illegal. Moving the declaration to the spec file
> (.ads) fixes the problem.
>
> Is it thus legal? Ada 2012?
> Since Loop_Times is a private method of Sprite package, I prefer then to
> call it in traditional manner:
> Loop_Times (Sprite, 0, TFin);
>
I don't think object.operation is legal on non primitive operations in any
version of Ada. Using package.operation(object) is a good fix. However,
don't forget you can put it in the private section of the spec and still
get both a private method and a primitive one for object.operation if you
so desire. I'm good either way.
> >
> > 3. For some reason on Ubuntu, it looks for gnoga-application-Linux and
> gnoga.application-Unix in the build process but the files are all lower
> case named. It builds fine on windows which is case insensitive but fails
> on Ubuntu which is strict on case. Renaming the files fixes the issue.
>
> Yes, it's a awful trick in gnoga.gpr which works on macOS (case
> insensitive file names with standard file system):
> for Body ("Gnoga.Application.Open_command") use
> "gnoga-application." & Settings.Build_Target;
>
> Here is a patch:
>
> diff --git a/src/gnoga.gpr b/src/gnoga.gpr
> index e480793b..198494ea 100644
> --- a/src/gnoga.gpr
> +++ b/src/gnoga.gpr
> @@ -11,7 +11,14 @@ project Gnoga is
> for Library_Kind use "static";
>
> package Naming is
> - for Body ("Gnoga.Application.Open_command") use
> "gnoga-application." & Settings.Build_Target;
> + case Settings.Build_Target is
> + when "Windows" =>
> + for Body ("Gnoga.Application.Open_command") use
> "gnoga-application.windows";
> + when "OSX" =>
> + for Body ("Gnoga.Application.Open_command") use
> "gnoga-application.osx";
> + when others =>
> + for Body ("Gnoga.Application.Open_command") use
> "gnoga-application.linux";
> + end case;
> end Naming;
>
> package Compiler renames Settings.Compiler;
>
>
> Does it work better?
>
I'll have to try it out next week to be sure. I'm at home tomorrow and my
ubuntu box is at work. Thanks.
> >
> > Thanks again.
> >
> > Side note: On the ubuntu box, I had to fix one of the zanyblue files in
> the text subdirectory becauase it was using Object'Image, which 5.4 doesn't
> support. However, when I search the copy I have on my windows machine, I
> don't find it. In both cases I used "git clone -b dev_1.4
> source/forge/path/to/gnoga gnoga-code" (both on today). Since I cant
> replicate it here, I don't have much to give. My ubuntu box is essentially
> standalone, so it is hard to get data off of it to here.
>
> With your following post:
>
> > Right after I sent the email I found it. Not in zany blue, but in
> >
> > components/ace_editor/src/gnoga-gui-plugin-ace_editor.adb:985:
> Row'Img & ',' & Column'Image & ");");
> >
> > It compiles fine in GNAT FSF 7.3 but not in 5.4. I don't know if
> Object'Image is legal Ada or not. It might be, but in my Ubuntu box with
> version 5.4, I changed it to Column'Img which is a GNAT extension.
>
>
> You're right, it's a mistake.
> As current Gnoga uses 'Img largely, I will correct it.
> As Jean-Pierre said I thought too it was for Ada 2020.
> But as Jeff noticed it is Ada 2012 so why don't use 'Image instead
> specific 'Img from GNAT?
> One more item in Gnoga todo list.
>
Since it is part of Ada2012 TC1, then yeah, it is ok to use. I wasn't sure
when I posted it.
I'm stuck with my old version of GNAT so I'll just manually patch the files
for this.
I'm currently building a Gnoga app on an Nvidia TX2 running Linux for Tegra
(L4T), an Ubuntu 16.04 variant. Unfortunately, the most recent version of
GNAT is 5.4 from 2015, but it is better than no Ada!
Thanks again!
Gmail <https://mail.google.com/mail/?tab=wm>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gnoga-list mailing list
Gnoga-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gnoga-list
