Re: [Gnoga-list] Errors in Gnoga.Gui.Element.Canvas.Context_2d

[Jeremiah Breeden]

Wayne,

I remember this being a thing a while back and it was fixed updated in a
later version of Gnoga.  Can you confirm what version of Gnoga you are
running?

On Tue, Mar 12, 2024 at 9:29 AM Wayne Bullaughey via Gnoga-list <
gnoga-list@lists.sourceforge.net> wrote:

> 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
>
>
> Wayne
>
>
> ___
> 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 1.5a installation failure with 32-bit TDM-GCC

[Jeremiah Breeden]

Just took a quick look.  See this part of the Makefile and maybe the
comment section after this one:

ATOMIC_ACCESS=Pragma-atomic
# If using GNAT which supports pragma Atomic for 64-bit scalar
variables for GNAT hosted on a 64-bit OS.
# You can set this to:
# ATOMIC_ACCESS=Pragma-atomic
# If the target is 32-bit. "GCC-long-offsets" is a workaround of the
GNAT bug on,
# that for a 32-bit target pragma Atomic does not support 64-bit
scalars even though the processor
# has corresponding quad-words instructions.
# You need change this to:
# ATOMIC_ACCESS=GCC-long-offsets
# If using GNAT GPL prior to 2014 or earlier on a 32bit host (Windows or Linux)
# You need to change this to:
# ATOMIC_ACCESS=GCC-built-ins

On Sun, Aug 30, 2020 at 7:22 PM Jeremiah Breeden 
wrote:

> It's been a while, but when Gnoga switched from 32bit to 64bit, the
> Makefile had a line that had to be manually swapped to enable 32bit.  I
> don't recall if it was the 32bit or the 64bit option but it had the word
> 'atomic' in it.  Look towards the beginning of the Makefile.
>
> On Sun, Aug 23, 2020 at 6:41 PM David Gressett 
> wrote:
>
>> I'm taking a new look at GNOGA, after giving it some time to develop. I'm
>> using the 32-bit TDM-GCC compiler (gcc v9.2.0) on Windows 10.
>>
>> make BUILD_MODE=Release install fails with 4 attomic access errors:
>>
>> gnat-sockets-server.ads:1416:22: error: atomic access to "First_Read"
>> cannot be guaranteed
>>
>> The next three errors are very similar; the offenders are "Free_to_Read",
>> "First_Written", and "Free_To_Write".
>>
>> Is there a fix for  this?
>>
>>
>>
>> ___
>> 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 1.5a installation failure with 32-bit TDM-GCC

[Jeremiah Breeden]

It's been a while, but when Gnoga switched from 32bit to 64bit, the
Makefile had a line that had to be manually swapped to enable 32bit.  I
don't recall if it was the 32bit or the 64bit option but it had the word
'atomic' in it.  Look towards the beginning of the Makefile.

On Sun, Aug 23, 2020 at 6:41 PM David Gressett 
wrote:

> I'm taking a new look at GNOGA, after giving it some time to develop. I'm
> using the 32-bit TDM-GCC compiler (gcc v9.2.0) on Windows 10.
>
> make BUILD_MODE=Release install fails with 4 attomic access errors:
>
> gnat-sockets-server.ads:1416:22: error: atomic access to "First_Read"
> cannot be guaranteed
>
> The next three errors are very similar; the offenders are "Free_to_Read",
> "First_Written", and "Free_To_Write".
>
> Is there a fix for  this?
>
>
>
> ___
> 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] GNAT CE 2020 problems

[Jeremiah Breeden]

Just a heads up, but in C.L.A someone posted some compiler problems with
GNAT CE 2020.  I haven't tested myself yet, but you might keep it in mind.

https://groups.google.com/forum/#!topic/comp.lang.ada/VvnHJ2iB8E0
___
Gnoga-list mailing list
Gnoga-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gnoga-list

Re: [Gnoga-list] SYSTEM.ASSERTIONS.ASSERT_FAILURE : Position cursor of Next is bad

[Jeremiah Breeden]

I always felt like my suggestion to restart on exception was more of a
bandaid.  I really wonder if honestly it just needs a look at the design.
Is it really a good idea to give two independent tasks delete power on the
container?  I feel like it is a design problem that the ping operation can
delete cursors.  So I would choose option (e), look at the design and see
if it can be reorganized.  If not, option (b) would be my second choice,
but that's without really knowing how the implementation would work out.

On Sun, Jul 21, 2019 at 11:57 AM Pascal via Gnoga-list <
gnoga-list@lists.sourceforge.net> wrote:

> Hello,
>
> Time from time the following exception occurs:
> 2019-03-01 20:22:56.99 : raised SYSTEM.ASSERTIONS.ASSERT_FAILURE :
> Position cursor of Next is bad
> [bin/adablog]
> System.Assertions.Raise_Assert_Failure at s-assert.adb:46
> Gnoga.Server.Connection.Socket_Maps.NextXnn at a-coorma.adb:1075
> Gnoga.Server.Connection.Connection_Manager.NextN at
> gnoga-server-connection.adb:1085
> Gnoga.Server.Connection.Connection_Manager.NextP at
> gnoga-server-connection.adb:1082
> Gnoga.Server.Connection.Watchdog_TypeT at gnoga-server-connection.adb:1268
>
> Watchdog piece of code:
> Connection_Manager.First (ID);
> while ID /= 0 loop
>Ping (ID);
>Connection_Manager.Next (ID);   --> exception raised
> end loop;
>
> I guess it fails when Current_Socket has been previous deleted:
>   procedure Next (ID : out Gnoga.Types.Connection_ID) is
>  use type Socket_Maps.Cursor;
>   begin
>  Current_Socket := Socket_Maps.Next (Current_Socket); -->
> exception raised
>  if Current_Socket /= Socket_Maps.No_Element then
> ID := Socket_Maps.Key (Current_Socket);
>  else
> ID := 0;
>  end if;
>   end Next;
>
> This issue has been discussed last year from Gautier ping issue:
>
> https://sourceforge.net/p/gnoga/mailman/gnoga-list/thread/2b62e268-6f8a-8bec-c249-4e90753fab1e%40adalog.fr/#msg36384899
>
> And Jere had opened a ticket and a discussion about a similar issue with
> the ID closing loop:
> https://sourceforge.net/p/gnoga/tickets/41/
> https://sourceforge.net/p/gnoga/mailman/message/36357020/
>
> Let's sum up ideas:
> a) include the watchdog loop into the protected object Connection_Manager,
> as Jeff proposed for Jere issue,
> What could possible side effects for watchdog case?
> b) declare a shadow socket container in the protected object
> Connection_Manager and clone active socket container into the shadow one
> when calling First and then iterating on the shadow container which will be
> safe, as Jeff proposed too,
> c) Add to the ID loop an exception handler which rewind the cursor to
> first, as Jere proposed,
> What could possible side effects for watchdog case?
> d) do nothing ;-)
>
> In my opinion, b) is a safer choice, c) is simple choice.
> What is your feedback?
>
> 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] Features for GNOGA V1.5.

[Jeremiah Breeden]

I don't seen any reason to hold it back.  My only question would be for the
submission I made.  I submitted two methods for doing modal dialogs:
gnoga.gui.modal_dialog and gnoga.gui.view.modal_dialog.  It probably isn't
good to have both methods as it might be confusing.  Should we axe one?  I
was hoping people would have a chance to use it and provide feedback on
which method they prefer

Either way, I think it is stable enough for beta

On Wed, Jul 31, 2019 at 10:24 PM Pascal via Gnoga-list <
gnoga-list@lists.sourceforge.net> wrote:

> Hello,
>
> Up to now here is the list of new features of GNOGA V1.5 alpha (versus
> 1.4):
> - Update Jeff Carter's Pragmarc and demos from Github
> - Upgrade to Simple Components 4.40
> - Canvas: add additional binding to drawImage
> - PIXI.Sprite: recursive rendering of sprite's children.
> - PIXI.Sprite: modification for finalizing children
> - Add log of user agent and platform client browser in case of suspicious
> connections
> - Make favicon customization available by the application.
> - Add an exception handler when a requested file is non existent on the
> server side
> - Support multi-part bodies for POST forms
> - Add Profile build mode and tidy some GPR project files.
> - Fix POST UTF-8 key, UTF-8 to Latin-1 translation, UTF8 incoming message.
> - Console_IO: improve responsiveness of Get_Line
> - Canvas_2D: add Polygon_To; Plotting_2D: use Polygon_To
>
> There are available on Gnoga SF repo:
> https://sourceforge.net/p/gnoga/code/ci/dev_1.5/tree/
>
> I propose to move in beta status for more testing unless you propose some
> additional features to add.
> What is your feedback?
>
> 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] Drag and Drop Horizontal Only

[Jeremiah Breeden]

Well, I was planning on something more complicated than I have seen sliders
present (kind of mimic'ing a mockup of a oscilloscope output so that someone
adjust the image to match what they want to see on the scope).  I can look
at
PIXI sprites as I am not super familiar with them and see if those can
help.

I am curious how they get the appropriate mouse info though.  The record
for the mouse events only returns screen X,Y and the X,Y relative to
whatever
component your mouse is over at the time.  I had trouble whenever I was
moving my object (manually) that when I moved across another element, the
X,Y coords would switch what they were relative to.  I'll have to see what
frame of reference the PIXI sprites return their X,Y coords relative to.

Thanks for the suggestion.  I'll look into it.  My hope was that there was
a
simple drag n drop solution I was missing, but this gives me something
to at least try and play with.

Thanks!

On Sat, Aug 10, 2019 at 2:25 AM Gautier de Montmollin 
wrote:

> Perhaps there is a horizontal slider widget that would do the job ?
>
> Otherwise you can set up a PIXI sprite and link its its X position to
> mouse movements.
>
>
> ___
> 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] Drag and Drop Horizontal Only

[Jeremiah Breeden]

I've been trying to figure out how to get a component to only be able to
drag along a horizontal path (so no vertical movement).  The drag event
handlers don't return anything related to the drag image as far as I can
tell (only the dragable component, but that stays where it is.  The jquery
one didn't seem useful in that respect either.  I tried manually doing the
drag using mouse events, but the mouse event record is missing some values
that would be useful to do that (it only provides the screen XY and the XY
relative to the component, but not the other XY options like relative to
the window..

Does anyone have any experience constraining a drag to just being
horizontal.  I want to be able to click into a component and only be able
to drag it left / right.
___
Gnoga-list mailing list
Gnoga-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gnoga-list

Re: [Gnoga-list] 5g and Gnoga

[Jeremiah Breeden]

I'm really hoping you stay with Ada honestly.  I've really enjoyed using
Gnoga.  If you have to look at any other languages, you might consider
Rust.  It has a huge growing community, the language development is really
integrated with the community, the toolset is good, it's llvm oriented, and
while not as good a language as Ada, it is better than C++ (At least in my
opinion).  It focuses mainly on memory safety.  The biggest flaw with it is
probably readability as it is a language not as readable as Ada, but I feel
it is better than C++ and similar languages.  But it definitely has a few
areas where it outperforms other languages, including Ada (Though I feel
Ada is still the better language all around).

On Fri, Jul 26, 2019 at 11:33 AM David Botton  wrote:

> I spent a bit more time concentrating this last year on recovery for my
> businesses and physically after the stroke I had last year that I expected.
> Thank God all is in full swing. The advent of 5g tech is going to swing the
> pendulum even more to always connected server based tech which is Gnoga’s
> big angle. I have a few ideas I plan on exploring using Gnoga (and also
> finishing up a form builder for Gnoga), but I would like to ask some
> opinions on the following:
>
> I am considering rewriting Gnoga in a language other than Ada (yes I love
> the old girl but for reasons I don’t want to debate she has terminal
> cancer), what other language would appeal to any of you?
>
> David Botton
> ___
> 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.com issues

[Jeremiah Breeden]

Thank you!

On Tue, Jul 2, 2019 at 7:45 PM David Botton  wrote:

> backup ... sorry I reset the machine and forgot to restart the gnoga
> apps
>
> On Tue, Jul 2, 2019 at 7:10 PM Jeremiah Breeden
>  wrote:
> >
> > David (the owner of the site) is aware.  I'm not sure if he will be
> putting it back up or not though.
> >
> > On Thu, Jun 27, 2019 at 1:09 PM Henrik Härkönen  wrote:
> >>
> >> Btw, for many days, the gnoga.com site has been answering with 503
> Service Unavailable:
> >>
> >> The server is temporarily unable to service your request due to
> maintenance downtime or capacity problems. Please try again later.
> >>
> >> 
> >> Apache/2.4.6 (Debian) Server at www.gnoga.com Port 80
> >>
> >> -Henrik
> >> ___
> >> 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
>
___
Gnoga-list mailing list
Gnoga-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gnoga-list

Re: [Gnoga-list] Gnoga.com issues

[Jeremiah Breeden]

David (the owner of the site) is aware.  I'm not sure if he will be putting
it back up or not though.

On Thu, Jun 27, 2019 at 1:09 PM Henrik Härkönen  wrote:

> Btw, for many days, the gnoga.com site has been answering with 503
> Service Unavailable:
>
> The server is temporarily unable to service your request due to
> maintenance downtime or capacity problems. Please try again later.
> --
> Apache/2.4.6 (Debian) Server at www.gnoga.com Port 80
>
> -Henrik
> ___
> 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] Installation issue

[Jeremiah Breeden]

Marc,

I've tried over the last few days and cannot reproduce your error.  maybe
someone with a similar system can have better luck.

On Mon, Apr 29, 2019 at 5:31 AM Marc BARDIN  wrote:

> Yes i did it of course.
>
> And i can say for sure, there is at least one error in gpr processing
> concerning the choice of the OS. This is in my file.
>
> Br
>
> Marc
>
>
>
> > Message du 29/04/19 05:21
> > De : "Jeremiah Breeden" 
> > A : "Gnoga support list" 
> > Copie à :
> > Objet : Re: [Gnoga-list] Installation issue
> >
> >
> Sorry, was looking at this through gmail interface, so I missed that you
> attached the tutorial_01.gpr file already.  It's definitely heavily
> modified.  Have you tried backing off all the options and getting to a
> smaller simpler GPR file that doesn't fail, then adding them back in one or
> two at a time until it breaks?
> >
>
> >
> On Sun, Apr 28, 2019 at 10:39 PM Jeremiah Breeden <
> jeremiah.bree...@gmail.com> wrote:
> >
>
>> Based on the paths you provided and the location of the tutorial.adb file
>> you gave in your original email, it looks like you changed up the relative
>> locations of all the files.  I think you might have a mistake in locating
>> something because of this change.
>>
>> >
>> You list tutorial.adb's path as
>> /media/4To/Donnees/Courrier/020-Ada/M-Sources/100-Gnoga/tutorial_01/A-src/tutorial_01.adb,
>> but the original tutorial_01 directory did not have a src directory
>> inside.  Additionally you moved settings.gpr to a different relative
>> position to the gnoga source.  Can you paste the contents of your
>> tutorial_01.gpr file here in an email.  I want to see the with lines and
>> all the locations of the src/exec/obj/etc.
>>
>> >
>> I was not personally able to replicate your error, but I am working from
>> windows and do not have linux (so that may be different then).  Maybe
>> someone working with linux has a better idea?  I may not be able to help
>> further if there is a linux related reason (will still try though).
>> >
>>
>> >
>> On Sun, Apr 28, 2019 at 6:52 AM Dubois  wrote:
>> >
>>
>>> > Thanks to all.
>>>
>>> > Marc
>>> >
>>>
>>> > --
>>> >
>>> 1.  What version of GNAT are you using?
>>> ~$ gnat
>>> >
>>>
>>> > GNAT 7.3.0
>>> > Copyright 1996-2017, Free Software Foundation, Inc.
>>> >
>>> > List of available commands
>>> >
>>> > gnat bind   gnatbind-7
>>> > gnat chop   gnatchop-7
>>> > gnat clean  gnatclean-7
>>> > gnat compilegnatmake-7 -f -u -c
>>> > gnat check  gnatcheck-7
>>> > gnat elim   gnatelim-7
>>> > gnat find   gnatfind-7
>>> > gnat krunch gnatkr-7
>>> > gnat link   gnatlink-7
>>> > gnat list   gnatls-7
>>> > gnat make   gnatmake-7
>>> > gnat metric gnatmetric-7
>>> > gnat name   gnatname-7
>>> > gnat preprocess gnatprep-7
>>> > gnat pretty gnatpp-7
>>> > gnat stack  gnatstack-7
>>> > gnat stub   gnatstub-7
>>> > gnat test   gnattest-7
>>> > gnat xref   gnatxref-7
>>> >
>>> 2.  What version of GPRBUILD do you have and why are you using gnatmake
>>> instead of gprbuild?
>>> ~$ gprbuild --version
>>> > GPRBUILD GPL 2017 (20170515) (x86_64-pc-linux-gnu)
>>> > Copyright (C) 2004-2017, AdaCore
>>> > This is free software; see the source for copying conditions.
>>> > There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
>>> PARTICULAR PURPOSE.
>>>
>>> >
>>> -I ignored it could run directly with gprbuild.
>>> gnatmake has an option to use directly gpr file, it's easy tu put all
>>> parameters in a gpr file, so..
>>> -What's the difference between the 2, please?
>>> >
>>>
>>> >
>>> 3.  What is the absolute path of the gnoga source directory and the
>>> settings.gpr file?
>>>
>>> > @PC:/media/4To/Donnees/Courrier/020-Ada$ ls
>>> > Install_trial  M-Sources  O-Projets  P-Exec  X-Bibliotheque
>>> Y-Outillage  Z-Doc
>>> 

Re: [Gnoga-list] Installation issue

[Jeremiah Breeden]

Sorry, was looking at this through gmail interface, so I missed that you
attached the tutorial_01.gpr file already.  It's definitely heavily
modified.  Have you tried backing off all the options and getting to a
smaller simpler GPR file that doesn't fail, then adding them back in one or
two at a time until it breaks?

On Sun, Apr 28, 2019 at 10:39 PM Jeremiah Breeden <
jeremiah.bree...@gmail.com> wrote:

> Based on the paths you provided and the location of the tutorial.adb file
> you gave in your original email, it looks like you changed up the relative
> locations of all the files.  I think you might have a mistake in locating
> something because of this change.
>
> You list tutorial.adb's path as
> /media/4To/Donnees/Courrier/020-Ada/M-Sources/100-Gnoga/tutorial_01/A-src/tutorial_01.adb,
> but the original tutorial_01 directory did not have a src directory
> inside.  Additionally you moved settings.gpr to a different relative
> position to the gnoga source.  Can you paste the contents of your
> tutorial_01.gpr file here in an email.  I want to see the with lines and
> all the locations of the src/exec/obj/etc.
>
> I was not personally able to replicate your error, but I am working from
> windows and do not have linux (so that may be different then).  Maybe
> someone working with linux has a better idea?  I may not be able to help
> further if there is a linux related reason (will still try though).
>
> On Sun, Apr 28, 2019 at 6:52 AM Dubois  wrote:
>
>> Thanks to all.
>>
>> Marc
>>
>> --
>> 1.  What version of GNAT are you using?
>> ~$ gnat
>>
>> GNAT 7.3.0
>> Copyright 1996-2017, Free Software Foundation, Inc.
>>
>> List of available commands
>>
>> gnat bind   gnatbind-7
>> gnat chop   gnatchop-7
>> gnat clean  gnatclean-7
>> gnat compilegnatmake-7 -f -u -c
>> gnat check  gnatcheck-7
>> gnat elim   gnatelim-7
>> gnat find   gnatfind-7
>> gnat krunch gnatkr-7
>> gnat link   gnatlink-7
>> gnat list   gnatls-7
>> gnat make   gnatmake-7
>> gnat metric gnatmetric-7
>> gnat name   gnatname-7
>> gnat preprocess gnatprep-7
>> gnat pretty gnatpp-7
>> gnat stack  gnatstack-7
>> gnat stub   gnatstub-7
>> gnat test   gnattest-7
>> gnat xref   gnatxref-7
>> 2.  What version of GPRBUILD do you have and why are you using gnatmake
>> instead of gprbuild?
>> ~$ gprbuild --version
>> GPRBUILD GPL 2017 (20170515) (x86_64-pc-linux-gnu)
>> Copyright (C) 2004-2017, AdaCore
>> This is free software; see the source for copying conditions.
>> There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
>> PARTICULAR PURPOSE.
>>
>> -I ignored it could run directly with gprbuild.
>> gnatmake has an option to use directly gpr file, it's easy tu put all
>> parameters in a gpr file, so..
>> -What's the difference between the 2, please?
>>
>> 3.  What is the absolute path of the gnoga source directory and the
>> settings.gpr file?
>>
>> @PC:/media/4To/Donnees/Courrier/020-Ada$ ls
>> Install_trial  M-Sources  O-Projets  P-Exec  X-Bibliotheque  Y-Outillage
>> Z-Doc
>>
>> @PC:/media/4To/Donnees/Courrier/020-Ada/M-Sources$
>>
>> @PC:/media/4To/Donnees/Courrier/020-Ada/O-Projets$
>>
>>
>> Le 28/04/2019 à 02:51, Jeremiah Breeden a écrit :
>>
>> I would guess it is either your version of GNAT and GPRBUILD or your
>> folder structure (this is more likely given your error).  The GPR file uses
>> relative paths for source and settings.  The path you showed is different
>> than the original gnoga path, so I don't know if you have all the other
>> files correctly located or not.  If you still need help, please answer the
>> following questions:
>>
>> 1.  What version of GNAT are you using?
>> 2.  What version of GPRBUILD do you have and why are you using gnatmake
>> instead of gprbuild?
>> 3.  What is the absolute path of the gnoga source directory and the
>> settings.gpr file?
>>
>> Please answer in full!  Thanks!
>> Jeremiah
>>
>> On Sat, Apr 27, 2019 at 8:03 AM Dubois  wrote:
>>
>>> Hi Jeremiah,
>>>it's a strange case, it doesn't work with the 1st option below
>>> (compilation1) but it works correctly (release) with the 2d one &  i have
>>> no any idea why !
>>>Your he

Re: [Gnoga-list] David

[Jeremiah Breeden]

I'm currently using 8.2 for GNAT and GCC, but I think 8.2.1 is available.
I don't believe it actually is GPRBUILD.  I think that GNAT and GCC for
msys2 are the outlier.  I have two versions of GPRBUILD available:  the one
from Adacore that is up to date and the one from the Gnoga SF repo.  Both
work find when building and installing using GNAT Community 2017 and 2018.
However, both fail to work when using the msys2 version of GNAT.  If it
were a GPRBUILD problem, I would expect that the Gnoga SF version to also
fail when using GNAT Community but it doesn't.  It works just fine.  Any
version of GPRBUILD that I try to use with the msys2 GNAT fails to work due
to the .exe extension issue.  My work around has been to go into those
locations and copy each of the gpr files from .gpr to .gpr.gpl and
then modify each of the original .gpr files to use the .exe in the name
and copy those to a .gpr.fsf.  That way, I can use a script to swap
between the version of the gprs that works with GNAT community and the
version that works with msys2 GNAT.  Though if I forget to do that before I
build, it can get messy.

As far as building GPRBUILD manually on msys2.  I've never gotten that to
work.  It never builds correctly.

On Sun, Apr 28, 2019 at 4:44 AM Pascal via Gnoga-list <
gnoga-list@lists.sourceforge.net> wrote:

>
> > Le 28 avr. 2019 à 05:56, Jeremiah Breeden 
> a écrit :
> >
> > Gnoga on Windows 64bit is a bit of a trial unless you are doing GNAT
> community.  The latest dev branch (1.5) doesn't even install properly when
> using msys2 (so I've stayed on 1.4 for now).  In terms of what you need to
> do:
> >
> > 1.  Update msys2 to latest GCC and GNAT along with all the necessary
> build tools like Make using pacman to install everything.
> > 2.  gprbuild...I haven't successfully built it on msys2 yet.  I grabbed
> the gprbuild from the Gnoga repo, but it doesn't work out of the box (it
> works with 32bit by default, not 64bit).  I copied the files into their
> correct locations in /mingw64/, then I used gprconfig to create a new .cpgr
> file and renamed it to the default one and put it in the appropriate share
> folder.  This got me gprbuild.  One thing I did not try but intend to at
> some point is to simply add my GNAT community version to the end of my
> path.  Maybe with my FSF first in the path, msys2 will pick up FSF GNAT for
> the compiler and then GNAT community's 64bit GPRBUILD for the build tools.
> > 3.  You have to manually modify gnoga-code/tools/tools.gpr,
> gnoga-code/deps/zanyblue/src/zbinfo/zbinfo.gpr, and
> gnoga-code/deps/zanyblue/src/zbmcompile/zbmcompile.gpr to add a .exe to the
> end of the executable names.  msys2's version of GNAT doesn't recognize the
> executable files otherwise.  I've mentioned this a few times in tickets and
> emails here, but I don't think anyone is gonna modify the build scripts
> (and I don't know how to do it), so if you want commercial ready Gnoga on
> windows, you'll need to do this yourself for now.
> >
> > I know this is a bit concise and I glossed over steps, but if you have
> trouble ask and I'll try and get you going with more specific ones.
>
> Hello Jeremiah,
>
> Which GNAT version is brought by msys2?
> Concerning GPRBuild, it seems that the version from Gnoga SF location is
> quite old and among things doesn't handle correctly exe extension for
> Window executables.
> GPRBuild is now available on GitHub from AdaCore:
> https://github.com/AdaCore/gprbuild.
> Could you build it from a newer version?
> (or anyone else with Windows because I haven't)
> If correct I will update it on Gnoga SF.
>
> Regards, 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] Installation issue

[Jeremiah Breeden]

Based on the paths you provided and the location of the tutorial.adb file
you gave in your original email, it looks like you changed up the relative
locations of all the files.  I think you might have a mistake in locating
something because of this change.

You list tutorial.adb's path as
/media/4To/Donnees/Courrier/020-Ada/M-Sources/100-Gnoga/tutorial_01/A-src/tutorial_01.adb,
but the original tutorial_01 directory did not have a src directory
inside.  Additionally you moved settings.gpr to a different relative
position to the gnoga source.  Can you paste the contents of your
tutorial_01.gpr file here in an email.  I want to see the with lines and
all the locations of the src/exec/obj/etc.

I was not personally able to replicate your error, but I am working from
windows and do not have linux (so that may be different then).  Maybe
someone working with linux has a better idea?  I may not be able to help
further if there is a linux related reason (will still try though).

On Sun, Apr 28, 2019 at 6:52 AM Dubois  wrote:

> Thanks to all.
>
> Marc
>
> --
> 1.  What version of GNAT are you using?
> ~$ gnat
>
> GNAT 7.3.0
> Copyright 1996-2017, Free Software Foundation, Inc.
>
> List of available commands
>
> gnat bind   gnatbind-7
> gnat chop   gnatchop-7
> gnat clean  gnatclean-7
> gnat compilegnatmake-7 -f -u -c
> gnat check  gnatcheck-7
> gnat elim   gnatelim-7
> gnat find   gnatfind-7
> gnat krunch gnatkr-7
> gnat link   gnatlink-7
> gnat list   gnatls-7
> gnat make   gnatmake-7
> gnat metric gnatmetric-7
> gnat name   gnatname-7
> gnat preprocess gnatprep-7
> gnat pretty gnatpp-7
> gnat stack  gnatstack-7
> gnat stub   gnatstub-7
> gnat test   gnattest-7
> gnat xref   gnatxref-7
> 2.  What version of GPRBUILD do you have and why are you using gnatmake
> instead of gprbuild?
> ~$ gprbuild --version
> GPRBUILD GPL 2017 (20170515) (x86_64-pc-linux-gnu)
> Copyright (C) 2004-2017, AdaCore
> This is free software; see the source for copying conditions.
> There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
> PARTICULAR PURPOSE.
>
> -I ignored it could run directly with gprbuild.
> gnatmake has an option to use directly gpr file, it's easy tu put all
> parameters in a gpr file, so..
> -What's the difference between the 2, please?
>
> 3.  What is the absolute path of the gnoga source directory and the
> settings.gpr file?
>
> @PC:/media/4To/Donnees/Courrier/020-Ada$ ls
> Install_trial  M-Sources  O-Projets  P-Exec  X-Bibliotheque  Y-Outillage
> Z-Doc
>
> @PC:/media/4To/Donnees/Courrier/020-Ada/M-Sources$
>
> @PC:/media/4To/Donnees/Courrier/020-Ada/O-Projets$
>
>
> Le 28/04/2019 à 02:51, Jeremiah Breeden a écrit :
>
> I would guess it is either your version of GNAT and GPRBUILD or your
> folder structure (this is more likely given your error).  The GPR file uses
> relative paths for source and settings.  The path you showed is different
> than the original gnoga path, so I don't know if you have all the other
> files correctly located or not.  If you still need help, please answer the
> following questions:
>
> 1.  What version of GNAT are you using?
> 2.  What version of GPRBUILD do you have and why are you using gnatmake
> instead of gprbuild?
> 3.  What is the absolute path of the gnoga source directory and the
> settings.gpr file?
>
> Please answer in full!  Thanks!
> Jeremiah
>
> On Sat, Apr 27, 2019 at 8:03 AM Dubois  wrote:
>
>> Hi Jeremiah,
>>it's a strange case, it doesn't work with the 1st option below
>> (compilation1) but it works correctly (release) with the 2d one &  i have
>> no any idea why !
>>Your help is welcomed.
>> Thks you
>> Regards
>> Marc
>> Ps : Full original file in attached piece.
>> I guess it's a problem with gpr file
>>
>> ___
>> Gnoga-list mailing list
>> Gnoga-list@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/gnoga-list
>>
>
>
> ___
> Gnoga-list mailing 
> listGnoga-list@lists.sourceforge.nethttps://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] David

[Jeremiah Breeden]

Found some of my cliffnotes as a reference for how I got it all working.
Haven't tested this in a while though:

http://www.msys2.org/
pacman -Sy make
pacman -Sy mingw-w64-x86_64-toolchain
download Gnoga
download gprbuild tools from Gnoga website
copy gprbuild tools to proper location
go to home directory
gprconfig --target=x86_64-w64-mingw32 --config=Ada batch
rename generated file to default.cgpr
copy default.cgpr to /share/gpr directory
modify gnoga project as needed  (all the .exe additions to various gpr
files)
make all
make install

I feel like the gprconfig one, I didn't end up specifying the --config flag
but instead manually selected the languages when prompted instead.  It's
been a while though.  I'd have to comb through the gprconfig documentation
again to be sure.

On Sat, Apr 27, 2019 at 11:56 PM Jeremiah Breeden <
jeremiah.bree...@gmail.com> wrote:

>
> 2.  gprbuild...I haven't successfully built it on msys2 yet.  I grabbed
> the gprbuild from the Gnoga repo, but it doesn't work out of the box (it
> works with 32bit by default, not 64bit).  I copied the files into their
> correct locations in /mingw64/, then I used gprconfig to create a new .cpgr
> file and renamed it to the default one and put it in the appropriate share
> folder.  This got me gprbuild.  One thing I did not try but intend to at
> some point is to simply add my GNAT community version to the end of my
> path.  Maybe with my FSF first in the path, msys2 will pick up FSF GNAT for
> the compiler and then GNAT community's 64bit GPRBUILD for the build tools.
>
>
>>
___
Gnoga-list mailing list
Gnoga-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gnoga-list

Re: [Gnoga-list] David

[Jeremiah Breeden]

Gnoga on Windows 64bit is a bit of a trial unless you are doing GNAT
community.  The latest dev branch (1.5) doesn't even install properly when
using msys2 (so I've stayed on 1.4 for now).  In terms of what you need to
do:

1.  Update msys2 to latest GCC and GNAT along with all the necessary build
tools like Make using pacman to install everything.
2.  gprbuild...I haven't successfully built it on msys2 yet.  I grabbed the
gprbuild from the Gnoga repo, but it doesn't work out of the box (it works
with 32bit by default, not 64bit).  I copied the files into their correct
locations in /mingw64/, then I used gprconfig to create a new .cpgr file
and renamed it to the default one and put it in the appropriate share
folder.  This got me gprbuild.  One thing I did not try but intend to at
some point is to simply add my GNAT community version to the end of my
path.  Maybe with my FSF first in the path, msys2 will pick up FSF GNAT for
the compiler and then GNAT community's 64bit GPRBUILD for the build tools.
3.  You have to manually modify gnoga-code/tools/tools.gpr,
gnoga-code/deps/zanyblue/src/zbinfo/zbinfo.gpr, and
gnoga-code/deps/zanyblue/src/zbmcompile/zbmcompile.gpr to add a .exe to the
end of the executable names.  msys2's version of GNAT doesn't recognize the
executable files otherwise.  I've mentioned this a few times in tickets and
emails here, but I don't think anyone is gonna modify the build scripts
(and I don't know how to do it), so if you want commercial ready Gnoga on
windows, you'll need to do this yourself for now.

I know this is a bit concise and I glossed over steps, but if you have
trouble ask and I'll try and get you going with more specific ones.

On Sat, Apr 27, 2019 at 9:55 PM Travis Ayres  wrote:

> While we're at it, can we talk about instructions for using Ada with
> MSYS2?
>
> On Sat, Apr 27, 2019, 6:52 PM David Botton  wrote:
>
>> Looks like power outage and ups dead. I’ll bring back up tomorrow and get
>> a new ups
>>
>> On Sat, Apr 27, 2019 at 7:47 AM Jeremiah Breeden <
>> jeremiah.bree...@gmail.com> wrote:
>>
>>> Have any of yall heard from David?  All 3 of his gnoga sites have gone
>>> down (www.gnoga.com, www.learnadanow.com, www.getadanow.com).
>>> ___
>>> 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
>
___
Gnoga-list mailing list
Gnoga-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gnoga-list

Re: [Gnoga-list] David

[Jeremiah Breeden]

Awesome!  Thanks.  Glad you are doing ok!

On Sat, Apr 27, 2019 at 9:52 PM David Botton  wrote:

> Looks like power outage and ups dead. I’ll bring back up tomorrow and get
> a new ups
>
> On Sat, Apr 27, 2019 at 7:47 AM Jeremiah Breeden <
> jeremiah.bree...@gmail.com> wrote:
>
>> Have any of yall heard from David?  All 3 of his gnoga sites have gone
>> down (www.gnoga.com, www.learnadanow.com, www.getadanow.com).
>> ___
>> 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] Installation issue

[Jeremiah Breeden]

I would guess it is either your version of GNAT and GPRBUILD or your folder
structure (this is more likely given your error).  The GPR file uses
relative paths for source and settings.  The path you showed is different
than the original gnoga path, so I don't know if you have all the other
files correctly located or not.  If you still need help, please answer the
following questions:

1.  What version of GNAT are you using?
2.  What version of GPRBUILD do you have and why are you using gnatmake
instead of gprbuild?
3.  What is the absolute path of the gnoga source directory and the
settings.gpr file?

Please answer in full!  Thanks!
Jeremiah

On Sat, Apr 27, 2019 at 8:03 AM Dubois  wrote:

> Hi Jeremiah,
>it's a strange case, it doesn't work with the 1st option below
> (compilation1) but it works correctly (release) with the 2d one &  i have
> no any idea why !
>Your help is welcomed.
> Thks you
> Regards
> Marc
> Ps : Full original file in attached piece.
> I guess it's a problem with gpr file
>
> ___
> 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] David

[Jeremiah Breeden]

Have any of yall heard from David?  All 3 of his gnoga sites have gone down
(www.gnoga.com, www.learnadanow.com, www.getadanow.com).
___
Gnoga-list mailing list
Gnoga-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gnoga-list

Re: [Gnoga-list] Installation issue

[Jeremiah Breeden]

Hi Marc,

I tried it on my machine using gprbuild and it worked fine:

$ gprbuild tutorial_01.gpr
Compile
   [Ada]  gnoga-application.adb
Build Libraries
   [gprlib]   gnoga.lexch
   [archive]  libgnoga.a
   [index]libgnoga.a
Bind
   [gprbind]  tutorial_01.bexch
   [Ada]  tutorial_01.ali
Link
   [link] tutorial_01.adb

Can you give more details on how you tried to build it (how did you
organize the files, version of GNAT and GPRBUILD, etc.)?

On Mon, Apr 8, 2019 at 5:16 PM Dubois  wrote:

> Hi world,
>   below is my 1st trial to compile Tutorial_1.adb.
>   Any idea, please?
> Thanks
> Regards
> Marc
> Ps : Attached file for install.
>
> -
>
>
> Dubois@PC:/media/4To/Donnees/Courrier/020-Ada/Y-Outillage/030-Gnoga/gnoga-1.4a$
> gnatmake -P/media/4To/Donnees/Courrier/020-Ada/O-Projets/tutorial_01
> Compile
>[Ada]  tutorial_01.adb
> Bind
>[gprbind]  tutorial_01.bexch
>[Ada]  tutorial_01.ali
> gcc: error: b__tutorial_01.adb: Aucun fichier ou dossier de ce type
> gcc: warning: ‘-x ada’ after last input file has no effect
> gcc: fatal error: no input files
> compilation terminated.
> gprbind: compilation of binder generated file failed
> gprbuild: unable to bind tutorial_01.adb
> gcc-7 -c -gnat2012 -gnata -gnatc -gnatf -gnaty -gnatw.eD -Wall -I- -gnatA
> /media/4To/Donnees/Courrier/020-Ada/M-Sources/100-Gnoga/tutorial_01/A-src/tutorial_01.adb
> gnatmake: "tutorial_01.ali" WARNING: ALI or object file not found after
> compile
> gnatmake:
> "/media/4To/Donnees/Courrier/020-Ada/M-Sources/100-Gnoga/tutorial_01/A-src/tutorial_01.adb"
> compilation error
>
> ___
> 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] Crash on ping

[Jeremiah Breeden]

Yep, this is what I meant by the Mutex operation.  A mutex is traditionally
just a binary semaphore (the implementation you chose).  I do the same
thing in a lot of my projects (a scope controlled mutex).  Thanks for the
example!

On Sat, Aug 4, 2018 at 8:59 AM, Björn Lundin  wrote:

> On 2018-08-04 04:03, Jeremiah Breeden wrote:
>
> Ok, with that in mind, the current set of loops are not being done
> atomically (it is not done inside a protected operation).  So the next
> question is how do we get to where they are done in a more atomic manner.
> I started off with a mutex like implementation for the close loop.since the
> close procedure could potentially block (and thus could not go in a
> protected operation).  That wouldn't work for the ping loop without
> restructuring the ping procedure itself (and pull out the deletions to be
> done afterwards as mentioned in an earlier email/post).
>
> At work, we sometimes (when tasking) use the pattern below.
>
> At the end there is a client package with procedures A and B which both
>
> may affect the same resourse.
>
> But both start with grabbing a common semaphore which
>
> will be autmatically released when out of scoope.
>
> This way we use the same protected object but with no blocking operations
> in it.
>
> But this is perhaps what you meant with mutex operation?
>
>
>
--
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

Re: [Gnoga-list] Crash on ping

[Jeremiah Breeden]

I did not realize that.  I've always followed the mantra taught to me about
not using
them in POs.  That's really neat.  Should we go ahead
and add a delete loop to it to prevent the potential for someone to start a
connection
between the close and the delete protected calls? Or do you think it will
be alright?

On Sat, Aug 4, 2018 at 5:10 AM, Jeffrey R. Carter  wrote:

> On 08/04/2018 04:03 AM, Jeremiah Breeden wrote:
> > Ok, with that in mind, the current set of loops are not being done
> atomically
> > (it is not done inside a protected operation).  So the next question is
> how do
> > we get to where they are done in a more atomic manner.  I started off
> with a
> > mutex like implementation for the close loop.since the close procedure
> could
> > potentially block (and thus could not go in a protected operation).  That
> > wouldn't work for the ping loop without restructuring the ping procedure
> itself
> > (and pull out the deletions to be done afterwards as mentioned in an
> earlier
> > email/post).
>
> With GNAT, which we have to use because Gnoga's in Ada 12, you can include
> potentially blocking operations in a PO, which is nice, because that
> restriction
> was a mistake. So I see no problem with putting these loops into protected
> operations. Modifying the Ping loop to create a structure of IDs to delete
> after
> the ping loop should be trivial.
>
>
--
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

Re: [Gnoga-list] Crash on ping

[Jeremiah Breeden]

Ok, with that in mind, the current set of loops are not being done
atomically (it is not done inside a protected operation).  So the next
question is how do we get to where they are done in a more atomic manner.
I started off with a mutex like implementation for the close loop.since the
close procedure could potentially block (and thus could not go in a
protected operation).  That wouldn't work for the ping loop without
restructuring the ping procedure itself (and pull out the deletions to be
done afterwards as mentioned in an earlier email/post).

On Fri, Aug 3, 2018 at 5:18 AM, Jeffrey R. Carter  wrote:

> On 08/03/2018 01:52 AM, Jeremiah Breeden wrote:
> > I'm not following on how whether it is atomic helps in this case.  Can
> you go
> > more into detail there?
> >
> > The issue I ran into (and I think the OP ran into) is that
> >
> > 1.  Task A gets a cursor and saves it,
> > 2.  does some process (either Ping or Close)
> > 3.  Iterates the cursor and saves the new one.
> > 4.  Repeats this in a loop until all cursors are checked
> >
> > but sometimes Task B deletes the element of that saved cursor while Task
> A is at
> > step 2.  Then when task A hits Step 3, the cursor is invalid and it
> throws an
> > exception.  Prior to the bandaid I suggested, if that happened during the
> > "close" loop, it would completely deadlock the close process.  The
> symptom for
> > my application was that when I hit the "terminate program" button, it
> wouldn't
> > terminate and future attempts to do so would not even try again.  The OP
> was
> > seeing some different results, but I suspect it has to do with the
> cursors as well.
> >
> > My understanding of Atomic in Ada is that it guarantees that
> writes/reads are
> > not interrupted and that they happen in the order specified.  In this
> case, the
> > problem isn't that the writes or reads are interrupted but that the map
> itself
> > is being modified while another task holds a cursor to it (thus making
> the
> > cursor invalid).  If this happens during the Ping loop, then it simply
> aborts
> > the pinging process (maybe/maybe not detrimental).  If it interrupts the
> Close
> > loop, then it (now) restarts the loop and tries again (before it
> deadlocked).
>
> I meant atomic in its generic sense, not as aspect/pragma Atomic. If the
> loop is
> an atomic operation (provided by the PO), then the other task cannot
> interfere
> with it. During the Close loop, the program is ending (IIUC), so it doesn't
> matter how long it takes. For Ping, how long the loop takes might be an
> issue,
> but since it's only done once per minute, if there aren't too many
> connections,
> it might be acceptable.
>
> --
> Jeff Carter
> "I like it when the support group complains that they have
> insufficient data on mean time to repair bugs in Ada software."
> Robert I. Eachus
> 91
>
> 
> --
> 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
>
--
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

Re: [Gnoga-list] Crash on ping

[Jeremiah Breeden]

I'm not following on how whether it is atomic helps in this case.  Can you
go more into detail there?

The issue I ran into (and I think the OP ran into) is that

1.  Task A gets a cursor and saves it,
2.  does some process (either Ping or Close)
3.  Iterates the cursor and saves the new one.
4.  Repeats this in a loop until all cursors are checked

but sometimes Task B deletes the element of that saved cursor while Task A
is at step 2.  Then when task A hits Step 3, the cursor is invalid and it
throws an exception.  Prior to the bandaid I suggested, if that happened
during the "close" loop, it would completely deadlock the close process.
The symptom for my application was that when I hit the "terminate program"
button, it wouldn't terminate and future attempts to do so would not even
try again.  The OP was seeing some different results, but I suspect it has
to do with the cursors as well.

My understanding of Atomic in Ada is that it guarantees that writes/reads
are not interrupted and that they happen in the order specified.  In this
case, the problem isn't that the writes or reads are interrupted but that
the map itself is being modified while another task holds a cursor to it
(thus making the cursor invalid).  If this happens during the Ping loop,
then it simply aborts the pinging process (maybe/maybe not detrimental).
If it interrupts the Close loop, then it (now) restarts the loop and tries
again (before it deadlocked).

I think we were trying to figure out if there was a better way to do this.
I agree with the Ping suggestion of deferring the deletions until after.
My 30 min attempt at making it better was to make the delete procedure an
entry, add a mutex like set of entries/procedures to the
connection_manager, seize the mutex before calling
Connection_Manager.First, and release the Mutex after the loop was done
(with the delete procedure now an entry, it would have to wait until after
the mutex was released).  That would work for the close loop, but the
deletions in the Ping function made it too complex to figure out in a short
time.  Plus I wasn't 100% certain it was a good idea or not to go that
route anyways.

Sorry for the long post!

On Tue, Jul 31, 2018 at 1:24 PM, Jeffrey R. Carter  wrote:

> On 07/30/2018 06:03 AM, Jeremiah Breeden wrote:
> > In Gnoga.Server.Connection.adb search for the two usages of
> > Connection_Manager.First.  Both will be in a loop.  Essentially, one of
> the
> > problems is that the First operation saves a cursor form the Map, and the
> > Connection_Manager.Next tries to iterate on it.  However, other tasks can
> > sometimes delete the element from the Map between those calls.  David
> recently
> > added a bandaid that I came up with (an Exception Handler around the
> "Close" one
> > to reset the loop if it happens).  The Ping one is already in an
> exception
> > handler, but the Ping function also calls Delete on the Map, so it can,
> in rare
> > cases, cause some weird crashes.  It's a bit of a hairy implementation
> and
> > probably needs a revamp.
>
> Usually these things should be atomic, and I don't see a problem with both
> of
> these being in Connection_Manager.
>
> Ping may delete using the ID that is then passed to Next. I'm not sure
> what that
> will do, but it's usually a bad idea. Better is to collect a set of IDs to
> delete and delete them after the iteration.
>
> I haven't tried any of this yet.
>
> --
> Jeff Carter
> "My brain hurts!"
> Monty Python's Flying Circus
> 21
>
> 
> --
> 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
>
--
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

Re: [Gnoga-list] Crash on ping

[Jeremiah Breeden]

In Gnoga.Server.Connection.adb search for the two usages of
Connection_Manager.First.  Both will be in a loop.  Essentially, one of the
problems is that the First operation saves a cursor form the Map, and the
Connection_Manager.Next tries to iterate on it.  However, other tasks can
sometimes delete the element from the Map between those calls.  David
recently added a bandaid that I came up with (an Exception Handler around
the "Close" one to reset the loop if it happens).  The Ping one is already
in an exception handler, but the Ping function also calls Delete on the
Map, so it can, in rare cases, cause some weird crashes.  It's a bit of a
hairy implementation and probably needs a revamp.

On Sat, Jul 28, 2018 at 4:27 AM, Jeffrey R. Carter  wrote:

> On 07/27/2018 08:08 PM, David Botton wrote:
> > I am looking (perhaps of Jeff wanted even better, this is his forte :) at
> > revamping, I think we need to improve the whole section from race
> conditions
> > with those maps.
>
> Can you point me at the code in question?
>
> --
> Jeff Carter
> "It is the German who is so uncourteous to his verbs."
> A Scandal in Bohemia
> 122
>
>
> 
> --
> 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
>
--
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

Re: [Gnoga-list] Crash on ping

[Jeremiah Breeden]

I actually tried to take a quick stab at it at home last week, but the
problem I quickly got caught in was the Ping procedure.  It does a lot more
than just ping, it also manages deletions, which made finding a good way to
prevent deletion on an ID while pinging a lot more complex.  I initially
started with a mutex style, but quickly found a simple application of it
wasn't going to work (maybe a more complex one though).  It seems like
finding a way to separate map management and pinging would help there, or
alternately (as you mentioned) an actual revamp/redo of it (which would
have been cleaner, I was just looking for a solution that I could gen out
and test in the 3 free hours I got after my son went to bed).

On Fri, Jul 27, 2018 at 2:08 PM, David Botton  wrote:

> I am looking (perhaps of Jeff wanted even better, this is his forte :) at
> revamping, I think we need to improve the whole section from race
> conditions with those maps.
>
> David Botton
>
> On Fri, Jul 27, 2018 at 1:45 PM Jeremiah Breeden <
> jeremiah.bree...@gmail.com> wrote:
>
>> Is it potentially related to the bug I submitted a fix for a week or two
>> ago?  I know the Ping operation in Gnoga.Server.Connection.adb occurred in
>> the same type of for loop that the Close operation did (between a
>> Connection_Manager.First and Connection_Manager.Next call whee the map
>> cursor could be deleted by another process.  I didn't submit a fix for the
>> ping side.
>>
>> On Thu, Jul 26, 2018 at 7:37 AM, Gautier de Montmollin <
>> gdem...@hotmail.com> wrote:
>>
>>> Hello,
>>>
>>> First Gnoga server crash, in 1 year of almost uninterrupted service in
>>> the Pasta! game!
>>>
>>> I put hereafter the trace-back in case someone wants (and knows how) to
>>> do something good about it...
>>>
>>> Cheers
>>>
>>> Gautier
>>>
>>> _
>>>
>>> 2018-07-22 06:26:30.09 : Ping on websocket - 27
>>> 2018-07-22 06:27:30.09 : Ping on websocket - 27
>>> 2018-07-22 06:27:30.10 : Ping 27 error.
>>> 2018-07-22 06:27:30.10 : raised GNAT.SOCKETS.SOCKET_ERROR : [10053]
>>> Software caused connection abort
>>>
>>> Here is the call stack trace-back:
>>>
>>> gnoga_dev_1.3-2017_04_11/deps/simple_components/atomic-
>>> access/gcc-long-offsets/gnat-sockets-server.adb:948
>>> [ Send_Socket (Client.Socket, Data, Last); ]
>>> gnoga_dev_1.3-2017_04_11/deps/simple_components/gnat-
>>> sockets-connection_state_machine-http_server.adb:3574
>>> [ Push (Client, Data (Pointer..Data'Last), Next); ]
>>> gnoga_dev_1.3-2017_04_11/deps/simple_components/gnat-
>>> sockets-connection_state_machine-http_server.adb:3886
>>> [ WebSocket_Blocking_Send (Client, Header,  True, False); ]
>>> gnoga_dev_1.3-2017_04_11/src/gnoga-server-connection.adb:1197  [
>>> Socket.WebSocket_Send ("0"); ]
>>> gnoga_dev_1.3-2017_04_11/src/gnoga-server-connection.adb:1240  [ Ping
>>> (ID); ]
>>>
>>> 
>>> --
>>> 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
>>>
>>
>> 
>> --
>> 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
>>
>
> 
> --
> 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
>
>
--
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

Re: [Gnoga-list] Crash on ping

[Jeremiah Breeden]

Is it potentially related to the bug I submitted a fix for a week or two
ago?  I know the Ping operation in Gnoga.Server.Connection.adb occurred in
the same type of for loop that the Close operation did (between a
Connection_Manager.First and Connection_Manager.Next call whee the map
cursor could be deleted by another process.  I didn't submit a fix for the
ping side.

On Thu, Jul 26, 2018 at 7:37 AM, Gautier de Montmollin 
wrote:

> Hello,
>
> First Gnoga server crash, in 1 year of almost uninterrupted service in
> the Pasta! game!
>
> I put hereafter the trace-back in case someone wants (and knows how) to
> do something good about it...
>
> Cheers
>
> Gautier
>
> _
>
> 2018-07-22 06:26:30.09 : Ping on websocket - 27
> 2018-07-22 06:27:30.09 : Ping on websocket - 27
> 2018-07-22 06:27:30.10 : Ping 27 error.
> 2018-07-22 06:27:30.10 : raised GNAT.SOCKETS.SOCKET_ERROR : [10053]
> Software caused connection abort
>
> Here is the call stack trace-back:
>
> gnoga_dev_1.3-2017_04_11/deps/simple_components/atomic-
> access/gcc-long-offsets/gnat-sockets-server.adb:948
> [ Send_Socket (Client.Socket, Data, Last); ]
> gnoga_dev_1.3-2017_04_11/deps/simple_components/gnat-
> sockets-connection_state_machine-http_server.adb:3574
> [ Push (Client, Data (Pointer..Data'Last), Next); ]
> gnoga_dev_1.3-2017_04_11/deps/simple_components/gnat-
> sockets-connection_state_machine-http_server.adb:3886
> [ WebSocket_Blocking_Send (Client, Header,  True, False); ]
> gnoga_dev_1.3-2017_04_11/src/gnoga-server-connection.adb:1197  [
> Socket.WebSocket_Send ("0"); ]
> gnoga_dev_1.3-2017_04_11/src/gnoga-server-connection.adb:1240  [ Ping
> (ID); ]
>
> 
> --
> 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
>
--
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

Re: [Gnoga-list] inability to stop server under some situations

[Jeremiah Breeden]

I went ahead and made a ticket for this.  Locally I made a bandaid fix:

Connection_Manager.First (ID);
while ID /= 0 loop
   begin
  Close (ID);
  Connection_Manager.Next (ID);
   exception
  when others =>
 Connection_Manager.First(ID); -- restart if cursor is deleted early
   end;
end loop;

It isn't a good long term solution probably, but I tested it with multiple
connections up and didn't seen any glaring issues.  I"m sure it breaks
something though.  It can potentially call Close() on the same ID twice, if
the exception occurs a few iterations down the line.  I don't know if that
is bad or not.  I also don't know if the same fix will work for the
Watchdog version of this bug (the one that pings all the IDs).  Starting
over there could be costly?

On Sat, Jun 30, 2018 at 10:58 AM, Jeremiah Breeden <
jeremiah.bree...@gmail.com> wrote:

> On both of my work computers (Windows 10 and Ubuntu 16.04, FSF and GPL
> versions of GNAT), I somewhat sporadically am unable to successfully call
> Gnoga.Application.Multi_Connect.End_Application.  It generates an error
> message mentioning a failure with the Next procedure and the server
> continues to run.  In all cases I am running the same exact code (though
> recompiled for each combination).
>
> I was wondering if this was something others have run into?  When I looked
> into the procedure, I found that it called Gnoga.Server.Connection.Stop and
> inside that was the following loop:
>
>  Connection_Manager.First (ID);
>  while ID /= 0 loop
> Close (ID);
> Connection_Manager.Next (ID);
>  end loop;
>
>
> I think what might be happening is that another part of gnoga is closing
> the connection inbetween the calls to Connection_Manager.First and
> Connection_Manager.Next (I see that Gnoga occasionally chooses to switch
> connection IDs for my current connection, though I don't really know why).
> It at least looks like a data race and seems like a plausible reason why
> End_Application stops working.
>
> Anyone have any thoughts on this?
>
--
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

Re: [Gnoga-list] building v1.4 in windows

[Jeremiah Breeden]

As a note, while testing 1.3 today, I found a similar issue to the "random
build directory" that is not present in 1.4.  If I use the command "make
all" with version 1.3, it generates a random directory named "home" and all
the subdirectories going to gnoga-code/build/*.  This does not occur in
version 1.4.  I am guessing it is something similar to what you fixed for
1.4, but a quick diff of the makefiles didn't reveal anything that jumped
out at me.  For reference, if my directory structure is:

d:/Program_Files/msys64/home/user/gnoga-code/

then running "make all" creates:

d:/home


On Fri, May 11, 2018 at 3:25 PM, Pascal via Gnoga-list <
gnoga-list@lists.sourceforge.net> wrote:

>
> > Le 11 mai 2018 à 02:04, Jeremiah Breeden  a
> écrit :
> >
> > Sorry for the late response.  I was working in a standalone environment,
> so it took a bit to get setup again.
> >
> > I was able to verify that this change fixes the case-sensitivity issue
> in linux and still works in windows
> >
>
> Thanks, Jeremiah, I'll push them to SF.
>
> Regards, Pascal.
> http://blady.pagesperso-orange.fr
>
>
>
> 
> --
> 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
>
--
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

Re: [Gnoga-list] Gnoga standalone compilation.

[Jeremiah Breeden]

I wasn't able to test out the windows version on my Windows 10 box since my
environment is MSYS2/MinGW64.  It works with the linux method though.  I
don't have a pure windows environment that has the make command, so I only
build gnoga through mingw

On Mon, Jul 9, 2018 at 12:52 PM, Pascal via Gnoga-list <
gnoga-list@lists.sourceforge.net> wrote:

>
> > Le 1 juil. 2018 à 18:03, Pascal  a écrit :
> >
> >>
> >> Le 9 juin 2018 à 13:01, Pascal via Gnoga-list <
> gnoga-list@lists.sourceforge.net> a écrit :
> >>
> >> Hello,
> >>
> >> I'll add a standalone compilation mode with Gnoga which doesn't need
> Gnoga install.
> >>
> >> For Unix like:
> >> (it is like gtkada-config)
> >> The script is created a first time with makefile and then can be use
> without makefile.
> >>
> >> Simply do:
> >> $ cd 
> >> $ make gnoga-config
> >> $ cd 
> >> $ gprbuild -P your-project.gpr your-main.adb
> `/build/bin/gnoga-config`
> >> (your-project.gpr just have to include 'with "gnoga";')
> >>
> >> You can also add /build/bin to your PATH and then just do:
> >> $ gprbuild -P your-project.gpr your-main.adb `gnoga-config`
> >>
> >> gnoga-config sets the search project directories for gprbuild.
> >>
> >
> > For Windows, I fear that I can't do the same.
> > Nevertheless, I can use Gautier trick:
> > make.cmd: mingw32-make %1 %2 %3 %4 %5 %6 %7 %8 %9
> >
> > Thus, makefile creates gnoga-config.cmd with up to 9 arguments with
> gnoga compilation options.
> >
> > Usage:
> >> cd 
> >> make gnoga-config
> >> cd 
> >> \build\bin\gnoga-config gprbuild -P your-project.gpr
> your-main.adb
> > (your-project.gpr just have to include 'with "gnoga";')
> >
> > You can also add \build\bin to your PATH and then just do:
> >> gnoga-config gprbuild -P your-project.gpr your-main.adb
> >
> > Could some Windows users test it?
> >
> > Has someone better ideas?
> >
> > Thanks, Pascal.
> > http://blady.pagesperso-orange.fr
> >
> > The modified 1.3 makefile:
> >
> > 
>
> Hello,
>
> I've pushed the modified Makefile to SF GIT branch dev_1.3.
>
> See INSTALL at section 4.
>
> If it's convenient for all Gnoga users, I will froze version 1.3.
>
> Regards, Pascal.
> http://blady.pagesperso-orange.fr
>
>
>
> 
> --
> 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
>
--
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

[Gnoga-list] inability to stop server under some situations

[Jeremiah Breeden]

On both of my work computers (Windows 10 and Ubuntu 16.04, FSF and GPL
versions of GNAT), I somewhat sporadically am unable to successfully call
Gnoga.Application.Multi_Connect.End_Application.  It generates an error
message mentioning a failure with the Next procedure and the server
continues to run.  In all cases I am running the same exact code (though
recompiled for each combination).

I was wondering if this was something others have run into?  When I looked
into the procedure, I found that it called Gnoga.Server.Connection.Stop and
inside that was the following loop:

 Connection_Manager.First (ID);
 while ID /= 0 loop
Close (ID);
Connection_Manager.Next (ID);
 end loop;


I think what might be happening is that another part of gnoga is closing
the connection inbetween the calls to Connection_Manager.First and
Connection_Manager.Next (I see that Gnoga occasionally chooses to switch
connection IDs for my current connection, though I don't really know why).
It at least looks like a data race and seems like a plausible reason why
End_Application stops working.

Anyone have any thoughts on this?
--
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

Re: [Gnoga-list] Execute_Script Timeout

[Jeremiah Breeden]

I don't have any real experience with Execute_Script, but I do agree that a
hard coded timeout does seem odd.  There may be a reason for it, but I
don't know off hand.  I don't have enough experience with JS execution to
know if it is idiomatic to repeat a script if it fails to execute or not.
That might be the determining factor.  Did the documentation indicate that
it would repeat attempts?

On Thu, Jun 21, 2018 at 3:29 AM, Miguel Angel Olivan 
wrote:

> Dear gnoga folks,
>
> I have encountered some timeout problems executing 
> Gnoga.Server.Connection.Execute_Script.
> If I understand the code correctly, this function tries to execute a script
> with a fixed timeout (3 seconds) If this execution reaches this timeout it
> *executes again* the script.
>
> Some thoughts and questions:
>
> - I have seen this fail under some circumstances: heavy load of script
> executions with Firefox as client. I haven't be able to reproduce with
> other clients.  I don't know if I'm doing something *peculiar*. Does anyone
> had similar behavior?
> - Three seconds seems a small timeout to me and a hardcoded one. Yes, I
> can modify as I want, but I wonder if this parameter could be passed as
> parameter of the Execute_Script function. If you like this approach and if
> it is useful for some people I can send a patch, it seems easy to implement
> (maybe with 3s default parameter in order to keep backwards compatibility,
> maybe a setter to the global variable, maybe the combination of the two
> approaches is the best...)
> - On the other hand the subsequent execution to a timeout seems a little
> risky to me. It assumes the idempotence of the executed script (a hard
> assumption? I agree that most of the calls are getting/setting properties
> and styles, so it fulfills idempotence, but the direct call still exists...
> and it is very useful to me)
>
> I will be pleased to hear experiences and comments about Execute_Script...
>
> Best
> Miguel Ángel
>
> 
> --
> 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
>
--
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

Re: [Gnoga-list] localhost

[Jeremiah Breeden]

No problem at all.  I only ran into it because I had on application at work
that I wanted to ensure was local machine only (and not exposed on the
external ethernet connection).  I started off following the comments for
the Initialize procedure which said to use "localhost" to do so, but it
didn't work for me (on the Ubuntu machine).  I later tried it out at home
on my windows 10 box with the same results.  Using the actual IP for
localhost works, just not the "localhost" string that is suggested.  I was
just wondering if it was only my two platforms or if it affected other ones
the same.

On Sat, May 26, 2018 at 1:50 PM, Jeffrey R. Carter  wrote:

> On 05/26/2018 07:43 PM, Jeremiah Breeden wrote:
> > Just to clarify:  That is with you setting up your application with:
> >
> > Gnoga.Application.Multi_Connect.Initialize
> > (Host => "localhost";
> > Port => 8080;
> >
> > instead of:
> >
> > Gnoga.Application.Multi_Connect.Initialize
> > (Host => "";
> > Port => 8080;
> >
> > correct?
>
> No. It seems I misunderstood. I do
>
> Gnoga.Application.Multi_Connect.Initialize;
>
> and then localhost:8080 works in my browser. I've never had need to
> specify the
> host.
>
> --
> Jeff Carter
> "He that hath no beard is less than a man."
> Much Ado About Nothing
> 132
>
> 
> --
> 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
>
--
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

Re: [Gnoga-list] localhost

[Jeremiah Breeden]

Just to clarify:  That is with you setting up your application with:

   Gnoga.Application.Multi_Connect.Initialize
 (Host=> "localhost";
  Port=> 8080;

instead of:

  Gnoga.Application.Multi_Connect.Initialize
 (Host=> "";
  Port=> 8080;

correct?

If I do the first one, then localhost:8080 doesn't work in my browser,
but if I do the second form then localhost:8080 does work in my
browser.

My work around has been:

  Gnoga.Application.Multi_Connect.Initialize
 (Host=> "127.0.0.1";
  Port=> 8080;


which does work with localhost:8080 in my browser as well


On Sat, May 26, 2018 at 11:02 AM, Jeffrey R. Carter 
wrote:

> On 05/26/2018 04:57 PM, Jeremiah Breeden wrote:
> > Anyone use "localhost" as your host for Gnoga apps?  I tried on both my
> ubuntu
> > 16.04 and windows 10 boxes but specifying "localhost" per the Initialize
> > procedure's comments doesn't seem to actually link it to localhost.  Not
> a huge
> > biggie as I can force it to 127.0.0.1 manually, but was curious if
> anyone had it
> > working with the value specified by the comments?
>
> I've used localhost:8080 with success.
>
> --
> Jeff Carter
> "He that hath no beard is less than a man."
> Much Ado About Nothing
> 132
>
> 
> --
> 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
>
--
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

[Gnoga-list] localhost

[Jeremiah Breeden]

Anyone use "localhost" as your host for Gnoga apps?  I tried on both my
ubuntu 16.04 and windows 10 boxes but specifying "localhost" per the
Initialize procedure's comments doesn't seem to actually link it to
localhost.  Not a huge biggie as I can force it to 127.0.0.1 manually, but
was curious if anyone had it working with the value specified by the
comments?
--
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

Re: [Gnoga-list] building v1.4 in windows

[Jeremiah Breeden]

On Sat, May 5, 2018 at 11:58 AM, Jeremiah Breeden  wrote:

> On Sat, May 5, 2018 at 5:11 AM, Pascal via Gnoga-list <
> gnoga-list@lists.sourceforge.net> wrote:
>
>> > Le 4 mai 2018 à 01:35, Jeremiah Breeden a écrit :
>> > 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?
>>
>> I agree with your analysis, maybe an issue with grpinstall.
>> It's ok on my side with gprinstall from GNAT GPL 2017, where does your
>> gprinstall come from?
>>
>>
> I use the one supplied here by the Gnoga Sourceforge site.  The gprbuild
> and gprinstall supplied by GNAT GPL 2017 targets a different architecture
> than minw64 so it doesn't work.
>
>
As an update, I tried pulling in the GPRBUILD and GPRINSTALL and other
programs from GNAT GPL 2017, but the issue still persisted.  If I don't
have ".exe" at the end of some generated files, then it barfs on them.  So
far I have discovered that it affects zbinfo, zbmcompile, gnoga_make, and
gnoga_doc.  There might be others, but there is a lot of output to even try
to parse.  Perhaps this is a windows specific issue?
--
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

Re: [Gnoga-list] building v1.4 in windows

[Jeremiah Breeden]

On Sat, May 5, 2018 at 5:11 AM, Pascal via Gnoga-list <
gnoga-list@lists.sourceforge.net> wrote:

> Thanks again Jeremiah for reporting,
>
> > Le 4 mai 2018 à 01:35, Jeremiah Breeden  a écrit :
> > >
> > > 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.
>
> Let us informed.
>
>
Sorry for the late response.  I was working in a standalone environment, so
it took a bit to get setup again.

I was able to verify that this change fixes the case-sensitivity issue in
linux and still works in windows
--
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

Re: [Gnoga-list] building v1.4 in windows

[Jeremiah Breeden]

On Sat, May 5, 2018 at 5:11 AM, Pascal via Gnoga-list <
gnoga-list@lists.sourceforge.net> wrote:

> > Le 4 mai 2018 à 01:35, Jeremiah Breeden  a
> écrit :
> > 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?
>
> I agree with your analysis, maybe an issue with grpinstall.
> It's ok on my side with gprinstall from GNAT GPL 2017, where does your
> gprinstall come from?
>
>
I use the one supplied here by the Gnoga Sourceforge site.  The gprbuild
and gprinstall supplied by GNAT GPL 2017 targets a different architecture
than minw64 so it doesn't work.
--
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

Re: [Gnoga-list] building v1.4 in windows

[Jeremiah Breeden]

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  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=Debu

Re: [Gnoga-list] building v1.4 in windows

[Jeremiah Breeden]

That's a good point on portability.  I think Gnoga could benefit from more
portability.  I think right now it still uses a lot of GNAT extensions like
'Unrestricted_Access, and I don't know if the other libraries like
Simple_Components rely on any or not.  On the flip side, I'm not aware of
any other compilers besides GNAT that implement 2012, so I guess there is
time before it would be beneficial (which is a shame!)..

It is neat that GNAT is implementing some 2020 possible features early.

On Thu, May 3, 2018 at 1:35 AM, Jean-Pierre Rosen  wrote:

> Le 03/05/2018 à 02:47, Jeremiah Breeden a écrit :
> > SNIPPED
> It is an Ada 2020 extension, so it is normal that older versions of Gnat
> don't support it.
>
> But the good fix is to use T'Image(Object) instead. Works since Ada83
> and does not depend on compiler or version.
>
> --
> J-P. Rosen
> Adalog
> 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
> Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
> http://www.adalog.fr
>
> 
> --
> 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
>
--
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

Re: [Gnoga-list] building v1.4 in windows

[Jeremiah Breeden]

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.

So I don't know if it is a bug or not, but it is something to at least
consider.

On Wed, May 2, 2018 at 8:35 PM, Jeremiah Breeden  wrote:

>
> 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.
>
> On Wed, May 2, 2018 at 3:17 PM, Pascal via Gnoga-list <
> gnoga-list@lists.sourceforge.net> wrote:
>
>>
>> > Le 2 mai 2018 à 02:39, Jeremiah Breeden  a
>> écrit :
>> >
>> > Build environment:
>> > mingw64/msys2 x86_64 GNAT 7.2 FSF on Windows 10
>> >
>> > I cloned the 1.4 branch and tried to make a build.  I started with a
>> "make all" command and after a bit it erred on:
>> >
>> > ***
>> > make[2]: Leaving directory '/home/Jere/gnoga-code-2018_05
>> _01/components/pixi'
>> > make -C mnmenu install
>> > make[2]: Entering directory '/home/Jere/gnoga-code-2018_05
>> _01/components/mnmenu'
>> > cp -p css/*.* ../../css
>> > cp -p html/*.* ../../html
>> > cp -p img/*.* ../../img
>> > cp -p js/*.* ../../js
>> > make[2]: Leaving directory '/home/Jere/gnoga-code-2018_05
>> _01/components/mnmenu'
>> > make[1]: Leaving directory '/home/Jere/gnoga-code-2018_05
>> _01/components'
>> > gprbuild -p --target=x86_64-w64-mingw32 -P src/gnoga.gpr
>> -XPRJ_TARGET=Windows
>> > gnoga.gpr:2:06: unknown project file: "lib_components.gpr"
>> > gprbuild: "src/gnoga.gpr" processing failed
>> > make: *** [Makefile:188: gnoga] Error 4
>> >
>> > ***
>> > SNIPPED...
>> > anyone know where I go from here?
>> >
>> >
>>
>> Thanks Jeremiah for reporting,
>>
>> Thanks for help log, it is really helpful for analysis.
>> The issue is cause by the wrong choice of PATH separator which is not the
>> same between Unix and Windows.
>>
>> Here is a patch for the makefile:
>>
>> diff --git a/Makefile b/Makefile
>> index bf6a37c7..c350701e 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -79,7 +79,7 @@ endif
>>
>>  PATHSEP=$(strip $(PATHSEP2))
>>
>> -ifeq ($(PRJ_TARGET),Windows)
>> +ifeq ($(BUILD_OS),Windows)
>> GPR_PROJECT_PATH_SEP=;
>>  else
>> GPR_PROJECT_PATH_SEP=:
>>
>> The separator choice should be good now.
>>
>> HTH, Pascal.
>> http://blady.pagesperso-orange.fr
>>
>>
>>
>> 
>> --
>> 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
>>
>
>
--
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

Re: [Gnoga-list] building v1.4 in windows

[Jeremiah Breeden]

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?

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.

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.

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.

On Wed, May 2, 2018 at 3:17 PM, Pascal via Gnoga-list <
gnoga-list@lists.sourceforge.net> wrote:

>
> > Le 2 mai 2018 à 02:39, Jeremiah Breeden  a
> écrit :
> >
> > Build environment:
> > mingw64/msys2 x86_64 GNAT 7.2 FSF on Windows 10
> >
> > I cloned the 1.4 branch and tried to make a build.  I started with a
> "make all" command and after a bit it erred on:
> >
> > ***
> > make[2]: Leaving directory '/home/Jere/gnoga-code-2018_
> 05_01/components/pixi'
> > make -C mnmenu install
> > make[2]: Entering directory '/home/Jere/gnoga-code-2018_
> 05_01/components/mnmenu'
> > cp -p css/*.* ../../css
> > cp -p html/*.* ../../html
> > cp -p img/*.* ../../img
> > cp -p js/*.* ../../js
> > make[2]: Leaving directory '/home/Jere/gnoga-code-2018_
> 05_01/components/mnmenu'
> > make[1]: Leaving directory '/home/Jere/gnoga-code-2018_05_01/components'
> > gprbuild -p --target=x86_64-w64-mingw32 -P src/gnoga.gpr
> -XPRJ_TARGET=Windows
> > gnoga.gpr:2:06: unknown project file: "lib_components.gpr"
> > gprbuild: "src/gnoga.gpr" processing failed
> > make: *** [Makefile:188: gnoga] Error 4
> >
> > ***
> > SNIPPED...
> > anyone know where I go from here?
> >
> >
>
> Thanks Jeremiah for reporting,
>
> Thanks for help log, it is really helpful for analysis.
> The issue is cause by the wrong choice of PATH separator which is not the
> same between Unix and Windows.
>
> Here is a patch for the makefile:
>
> diff --git a/Makefile b/Makefile
> index bf6a37c7..c350701e 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -79,7 +79,7 @@ endif
>
>  PATHSEP=$(strip $(PATHSEP2))
>
> -ifeq ($(PRJ_TARGET),Windows)
> +ifeq ($(BUILD_OS),Windows)
> GPR_PROJECT_PATH_SEP=;
>  else
> GPR_PROJECT_PATH_SEP=:
>
> The separator choice should be good now.
>
> HTH, Pascal.
> http://blady.pagesperso-orange.fr
>
>
>
> 
> --
> 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
>
--
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

[Gnoga-list] building v1.4 in windows

[Jeremiah Breeden]

Build environment:
mingw64/msys2 x86_64 GNAT 7.2 FSF on Windows 10

I cloned the 1.4 branch and tried to make a build.  I started with a "make
all" command and after a bit it erred on:

***
make[2]: Leaving directory
'/home/Jere/gnoga-code-2018_05_01/components/pixi'
make -C mnmenu install
make[2]: Entering directory
'/home/Jere/gnoga-code-2018_05_01/components/mnmenu'
cp -p css/*.* ../../css
cp -p html/*.* ../../html
cp -p img/*.* ../../img
cp -p js/*.* ../../js
make[2]: Leaving directory
'/home/Jere/gnoga-code-2018_05_01/components/mnmenu'
make[1]: Leaving directory '/home/Jere/gnoga-code-2018_05_01/components'
gprbuild -p --target=x86_64-w64-mingw32 -P src/gnoga.gpr
-XPRJ_TARGET=Windows
gnoga.gpr:2:06: unknown project file: "lib_components.gpr"
gprbuild: "src/gnoga.gpr" processing failed
make: *** [Makefile:188: gnoga] Error 4

***

I remebered that we needed to set the GPR_PROJECT_PATH, so I did a make
help:
***
$ make help
-
--
--
-- make 
--
--
--
--  ::= help-- print this message
--
-- | all   -- build gnoga and all dependencies (debug
mode)--
-- | release   -- build gnoga in release mode
--
-- | install   -- install gnoga release mode
--
-- | install_debug -- install gnoga debug mode
--
-- | uninstall -- uninstall gnoga
--
-- | demo  -- build all demos
--
-- | tutorials -- build all tutorials
--
-- | gnoga_tools   -- build all tools
--
-- | tests -- build all tests
--
-- | clean -- clean build files
--
-- | clean_all -- clean build files and deps
--
-- | rm-docs   -- build reference manual
--
-- | html-docs -- build html docs
--
-- | gps   -- launch GPS with gnoga environnement
--
-- | check_rules   -- check gnoga with AdaControl
--
--
--
-- PREFIX   =
/home/Jere/gnoga-code-2018_05_01/inst_folder
--
-- GPRCHECK = GPRBUILD GPL 2016 (20160515)
(i686-pc-mingw32) Copyright (C) 2004-2016, AdaCore This is free software;
see the source for copying conditions. There is NO warranty; not even for
MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.  --
-- TARGET   =
x86_64-w64-mingw32--
-- GPR_PROJECT_PATH =
/home/Jere/gnoga-code-2018_05_01/build/share/gpr;/home/Jere/gnoga-code-2018_05_01/build/lib/gnat
--
-- ATOMIC_ACCESS= GCC-long-offsets
--
-- BUILDER  = gprbuild -p
--target=x86_64-w64-mingw32   --
-- PRJ_TARGET   = Windows--
-- BUILD_OS = UnixLike  --
--
--
-

***

when I tried to set the GPR_PROJECT_PATH using that value, I got:

$ set
GPR_PROJECT_PATH=/home/Jere/gnoga-code-2018_05_01/build/share/gpr;/home/Jere/gnoga-code-2018_05_01/build/lib/gnat
bash: /home/Jere/gnoga-code-2018_05_01/build/lib/gnat: No such file or
directory

anyone know where I go from here?
--
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

Re: [Gnoga-list] Newbie gnoga questions...

[Jeremiah Breeden]

I wish I could help with the reason the connection is lost, but I don't
know enough about Gnoga to answer that.  That's more of a Pascal or David
question.  If a connection is truly lost, you do have some ways to run code
at that point.  If running Singleton apps, just use the code space after
your call to Application.Singleton.Message_Loop.  If in multi-connect, then
go to you On_Connect handler for the connection and put a Connection.Hold;
line at the bottom of it.  It will hold the thread there until the
connection is lost.  Now you can either put code below that line that will
run when the connection is lost or setup your own custom handler.  Since
Gnoga events are concurrent, holding the On_Connect handler won't affect
your GUI functionality (assuming it is after your code that actually
generates the GUI layout).  NOTE:  I don't know if exceptions bypass this,
so you may need to catch an exception first or something...not sure.

Separately, it might also be worth your while to look at the private full
view of both Window_Type and Base_Type
https://sourceforge.net/p/gnoga/code/ci/dev_1.3/tree/src/gnoga-gui-window.ads
https://sourceforge.net/p/gnoga/code/ci/dev_1.3/tree/src/gnoga-gui-base.ads

It will list all the possible events for the Window and most other Gnoga
components.  For individual specialized Gnoga components, check out their
definitions.

The prospect of Ada on android has always got me excited.  I'm hoping it
does continue to develop.

On Wed, Jan 10, 2018 at 12:39 PM, Brian Drummond 
wrote:

> On Tue, 2018-01-09 at 23:38 -0500, Jeremiah Breeden wrote:
> > Wouldn't MyView.Width just return the width of that view?  On a phone
> > it would be similar to the screen size, but on something like a
> > laptop or desktop it might not be (depends on if the browser is
> > maximized or not).  Something to consider at least.
>
> Indeed, it is the browser window size upon opening, which is good
> enough for current purposes.
>
> However one part of the picture I don't get is how my View can get
> notified when something changes : e.g. the width changes (I rotated the
> phone) or the connection is lost (that background Ping fails to respond
> for some reason).
>
> For Destroy events, I can attach an On_Destroy_Handler
>   View.On_Destroy_Handler (On_Destroy'Access);
> and On_Destroy gets called as expected, but what can I do about other
> types of change imposed on my View (size, dropped connection) by the
> client (browser)?
>
> Been through the tutorial and some of the demos but missed this.
>
> Thanks for your help!
>
> -- Brian
>
> (ps : why is the phone of interest?
>
> Some years ago John Marino got a bare Ada compiler going on Android -
> http://www.dragonlace.net/
> and I managed to reproduce that work but made no progress on
> integrating the GUI via the NDK.
>
> Seems to me that if that can be made to work, perhaps Gnoga on the
> phone/tablet via its own browser, might be a practical way to develop
> without having to deal with the Java level or NDK)
>
--
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

Re: [Gnoga-list] Newbie gnoga questions...

[Jeremiah Breeden]

Wouldn't MyView.Width just return the width of that view?  On a phone it
would be similar to the screen size, but on something like a laptop or
desktop it might not be (depends on if the browser is maximized or not).
Something to consider at least.

On Sun, Jan 7, 2018 at 6:24 PM, Brian Drummond wrote:

> On Sun, 2018-01-07 at 09:38 -0500, Jeremiah Breeden wrote:
> > I can't help with the exception, but for the screen size thing, have
> > you tried out the Gnoga.Gui.Screen package?  Does it supply what you
> > need?
>
> Thanks! Actually, it's simpler than that : MyView.Width gives the
> answer.
>
> Still having trouble with my phone dropping connections though.
>
> -- Brian
>
>
--
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

[Gnoga-list] Fwd: Version 1.3a released and version 1.4-alpha created.

[Jeremiah Breeden]

Realized this wasn't sent to the Gnoga list directly.  here was the
correspondence:

-- Forwarded message --
From: Jeremiah Breeden 
Date: Sun, Jan 7, 2018 at 1:00 PM
Subject: Re: [Gnoga-list] Version 1.3a released and version 1.4-alpha
created.
To: Pascal 


Sorry, I realized late that I attached the wrong output.  I accidentally
attached the one where I was messing around.  Here is the correct output
where I correctly set the GPR_PROJECT_PATH

The file is attached.


On Sun, Jan 7, 2018 at 10:22 AM, Jeremiah Breeden <
jeremiah.bree...@gmail.com> wrote:

> Ok, sorry for the late response.  I previously thought that everything was
> working correctly, but the December versions I pulled after the changes
> actually didn't work.  What happened was my own patched version from
> November wasn't removed by make uninstall (using the December version of
> the Gnoga Makefile) and was supplementing the newer releases.
>
> I didn't realize how extensive the makefile changes were.  In the November
> release, make install/uninstall automatically worked with my GNAT
> installation.  Starting with the December one, it requires me to specify
> the installation directory (which I couldn't get to work at all).  However,
> everything only built because of the old November installation that I
> accidentally left in.  I started with a clean build with a version that I
> pulled today 01/07/2018.  It cannot find lib components anymore.
>
> Note that I did setup GPR_PROJECT_PATH (it is in the attached file).  I
> used tabbed completion to create the path so it should be correct.
>
> Attached is my command history for trying to make Gnoga on my platform
> (windows 10, mingw64, GCC 7.2 FSF,  GPRBUILD supplied by Gnoga website)
>
> Any suggestions?
>
> On Fri, Jan 5, 2018 at 2:53 PM, Pascal  wrote:
>
>>
>> > Le 11 déc. 2017 à 13:57, Jeremiah Breeden 
>> a écrit :
>> >
>> > I unset the environment variable and redid it and it works now.  Sorry
>> about that.  I'm guessing I misspelled the variable or something last time
>> (I used tab completion for the path, so it should have been correct
>> regardless).  It now correctly fails on tutorial 10 (I don't have sqlite
>> 3).  Side question:  should failures to build tutorials (or demos) be hard
>> make failures?  It might be good to have the makefile ignore those and keep
>> going.
>> >
>> > One other update.  I installed GNAT GPL 2017 and tried it.  The issue I
>> had with the tools.gpr not finding the exe files doesn't exist for the
>> Adacore supplied GPRBuild vs the Gnoga sourceforge supplied version.  This
>> suggests either a configuration issue or a build issue.  I've been looking
>> through the GPRbuild documentation but haven't run across anything about
>> setting known file extension types yet.  It's weird that the Adacore one
>> doesn't need you to specify .exe while the gnoga supplied version does.
>> >
>> > Sorry for the trouble.  Thanks again!
>>
>> Hello Jere,
>>
>> I wish happy new year to you and your family.
>>
>> Is it all ok on your side with Gnoga 1.3?
>>
>> I've pushed a last commit for branch dev_1.3 with INSTALL wording
>> reworked.
>>
>> May I froze the 1.3a version from your point of vue?
>>
>> Season's Greetings, Pascal.
>> http://blady.pagesperso-orange.fr
>>
>>
>>
>
Jere@XYZ MINGW64 ~
$ cd gnoga-code-2018_01_07/

Jere@XYZ MINGW64 ~/gnoga-code-2018_01_07
$ 
GPR_PROJECT_PATH=/d/Program_Files/msys64/mingw64/share/gpr:/d/Program_Files/msys64/mingw64/lib/gnat

Jere@XYZ MINGW64 ~/gnoga-code-2018_01_07
$ echo $GPR_PROJECT_PATH
/d/Program_Files/msys64/mingw64/share/gpr:/d/Program_Files/msys64/mingw64/lib/gnat

Jere@XYZ MINGW64 ~/gnoga-code-2018_01_07
$ make sqlite3
mkdir lib
mkdir: cannot create directory ‘lib’: File exists
make: [Makefile:148: lib/libsqlite3.a] Error 1 (ignored)
cd deps/simple_components/sqlite-sources && gcc -s -c -O2 -o sqlite3.o sqlite3.c
cd deps/simple_components/sqlite-sources && ar rcs libsqlite3.a sqlite3.o
cd deps/simple_components/sqlite-sources && mv libsqlite3.a ../../../lib
cd deps/simple_components/sqlite-sources && rm -f sqlite3.o

Jere@XYZ MINGW64 ~/gnoga-code-2018_01_07
$ make all
gprbuild -p --target=x86_64-w64-mingw32 -P 
deps/simple_components/lib_components.gpr -XAtomic_Access=GCC-long-offsets 
-XLegacy=Ada2012
gcc -c -g -gnatwcikmoprvz.c.p.t.w.x -gnato -gnatVa -gnatf -g -fstack-check 
-gnat12 parsers-multiline_source-xpm.ads
gcc -c -g -gnatwcikmoprvz.c.p.t.w.x -gnato -gnatVa -gnatf -g -fstack-check 
-gnat12 parsers-generic_source-xpm.adb
parsers-generic_source-xpm.adb:360:10: warn

Re: [Gnoga-list] Newbie gnoga questions...

[Jeremiah Breeden]

I can't help with the exception, but for the screen size thing, have you
tried out the Gnoga.Gui.Screen package?  Does it supply what you need?

On Sat, Jan 6, 2018 at 6:40 PM, Brian Drummond 
wrote:

> Just started playing with Gnoga, my first project is data logging and
> display from a cheap DAQ (measuring voltages, switching battery
> charger/test loads to measure battery capacity.
>
> I'm setting this up as a multi-connect, displaying graphs on a Canvas.
>
> Couple of questions:
>
> 1) How do I interrogate a connection to find out its screen size, so I
> can size the graph for a browser running on a laptop, a tablet, or a
> smartphone?
>
> I'm guessing, given
>procedure Default
>  (Main_Window : in out Gnoga.Gui.Window.Window_Type'Class;
>   Connection  : access
> Gnoga.Application.Multi_Connect.Connection_Holder_Type)
> I can interrogate Connection somehow?
>
> 2) I've seen exceptions linked to dropped connections, e.g.
>
> 2018-01-06 21:40:55.55 : Ping on websocket - 1
> 2018-01-06 21:40:55.55 :
> Ping on websocket - 2
> 2018-01-06 21:41:55.55 : Ping on websocket - 1
> 2018
> -01-06 21:41:55.55 : Ping on websocket - 2
> 2018-01-06 21:42:55.55 : Ping
> on websocket - 1
> 2018-01-06 21:48:44.06 : Websocket connection closed - ID 1
> 2018-01-06 21:48:44.06 : Deleting connection - 1
> 2018-01-06 21:48:44.06 : Ping 1 error.
> 2018-01-06 21:48:44.06 : raised ADA.IO_EXCEPTIONS.END_ERROR : WebSocket
> is being closed
> Call stack traceback locations:
> 0x558f8990b219 0x558f8990e257 0x558f899a985d 0x7f5c1c3d
> 0x7f5c1bc02492 0x7f5c1b526afd 0xfffe
>
> ... now addr2line doesn't seem to like generating backtraces (though I
> think I installed gnoga with debug info).
> addr2line --exe=bin/voltmeter 0x7fb9fbcceca3 0x7fb9fbcd094a
> 0x55aacc6f57b0 0x55aacc79f319 0x55aacc7a2514 0x55aacc823008
> 0x55aacc83d3aa 0x55aacc877f8e 0x55aacc878428 0x55aacc84d2db
> 0x55aacc7c107b 0x55aacc7c2456 0x55aacc88848c 0x55aacc83e3fb
> 0x7fb9fbfbe222 0x7fb9fb7ee492 0x7fb9fb112afd 0xfffe
> ??:0
> ??:0
> ??:0
> ??:0
> ??:0
> ...
>
> Near as I can tell,
> https://www.reddit.com/r/ada/comments/68ibwl/exception_traceback_in_gna
> tgcc_6/
> points at PIE being involved ...
> any suggestions how to get good backtraces (preferably without
> addr2line)?
>
> Cheers, and thanks for a great tool!
> -- Brian
>
> 
> --
> 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
>
--
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

Re: [Gnoga-list] Grid panel parent's view.

[Jeremiah Breeden]

Jeffrey's solution is probably the cleanest.  Some alternates:

Rosen Technique:
Change your declaration to:

*
   type Default_View_Type;

   type Button_With_Parent(Parent : not null access Default_View_Type)
  is new Gnoga.Gui.Element.Common.Button_Type with null record;

   type Default_View_Type is new Gnoga.Gui.View.Grid.Grid_View_Type with
record
  Label_Text   : Gnoga.Gui.View.View_Type;
  Click_Button : Button_With_Parent(Default_View_Type'Access);
   end record;
*

And then your click handler to:

*
   procedure On_Click (Object : in out Gnoga.Gui.Base.Base_Type'Class) is
  Button : Button_With_Parent renames Button_With_Parent(Object);
  View   : Default_View_Type  renames Button.Parent.all;
   begin
  View.Label_Text.Put_Line ("Click");
   end On_Click;
*

another option is an event listener paradigm, but it is probably too
complex for
something like this.  There is a write up at:
https://sourceforge.net/p/gnoga/code/ci/dev_1.3/tree/docs/articles/event_listeners.txt

NOTE:  noticed that my last name was incorrectly spelled.  It is Breeden.

This method involves making the button an event generator and the view a
listener.  It's not very
clean though.  Jeff's solution seems like the best to me.

On Fri, Dec 22, 2017 at 5:29 AM, Pascal via Gnoga-list <
gnoga-list@lists.sourceforge.net> wrote:

> Hello,
>
> After declaration of my view:
>type Default_View_Type is new Gnoga.Gui.View.Grid.Grid_View_Type with
> record
>   Label_Text   : Gnoga.Gui.View.View_Type;
>   Click_Button : Gnoga.Gui.Element.Common.Button_Type;
>end record;
>
> and creation of my objects:
>   Gnoga.Gui.View.Grid.Grid_View_Type (Grid).Create  (Parent, Layout,
> Fill_Parent, Set_Sizes, ID);
>   Grid.Label_Text.Create (Grid.Panel (1, 1).all);
>   Grid.Click_Button.Create (Grid.Panel (1, 2).all, "Click Me");
>
> My button controller is:
>procedure On_Click (Object : in out Gnoga.Gui.Base.Base_Type'Class) is
> --View : Logo.View.Default_View_Access :=
> --  Logo.View.Default_View_Access (Object.Parent);
>begin
>   --View.Label_Text.Put_Line ("Click");
>   gnoga.log(ada.Tags.Expanded_Name(Object.Parent'tag));
>end On_Click;
>
> I've got a CE:
> raised CONSTRAINT_ERROR : logo-controller.adb:14 tag check failed
>
> because of object parent's type:
> GNOGA.GUI.VIEW.VIEW_BASE_TYPE
>
> How to get the true parent that is Default_View_Type and then access to
> Label_Text?
>
> Thanks for help, Pascal.
> http://blady.pagesperso-orange.fr
>
>
>
> 
> --
> 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
>
--
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

[Gnoga-list] Falling off the edge of the earth ... err server

[Jeremiah Breeden]

So I had a question.  What happens when your connection ID's max out?  How
does Gnoga handle that?  Does it stop taking connections and you have to do
a full reset to start over (disconnecting anyone still connected)?  I
realize it would take a long time for that to happen, but was curious.
Digging through the code I could not find any handling for that and as far
as I can tell, it just increments the ID for each new connection until an
exception is thrown
(Gnoga.Server.Connection.Connection_Manager.Add_Connection).
--
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

Re: [Gnoga-list] Version 1.3a released and version 1.4-alpha created.

[Jeremiah Breeden]

I unset the environment variable and redid it and it works now.  Sorry
about that.  I'm guessing I misspelled the variable or something last time
(I used tab completion for the path, so it should have been correct
regardless).  It now correctly fails on tutorial 10 (I don't have sqlite
3).  Side question:  should failures to build tutorials (or demos) be hard
make failures?  It might be good to have the makefile ignore those and keep
going.

One other update.  I installed GNAT GPL 2017 and tried it.  The issue I had
with the tools.gpr not finding the exe files doesn't exist for the Adacore
supplied GPRBuild vs the Gnoga sourceforge supplied version.  This suggests
either a configuration issue or a build issue.  I've been looking through
the GPRbuild documentation but haven't run across anything about setting
known file extension types yet.  It's weird that the Adacore one doesn't
need you to specify .exe while the gnoga supplied version does.

Sorry for the trouble.  Thanks again!

On Sun, Dec 10, 2017 at 1:33 PM, Pascal via Gnoga-list <
gnoga-list@lists.sourceforge.net> wrote:

> Hello Jeremiah,
>
> The error gnoga.gpr:2:06: unknown project file: "lib_components.gpr" at
> the end of log indicates that GPR_PROJECT_PATH is not well set.
>
> Can you just send the print log of "make help" for confirmation?
>
> Thanks for your help, Pascal.
> http://blady.pagesperso-orange.fr
>
>
> > Le 10 déc. 2017 à 18:03, Jeremiah Breeden 
> a écrit :
> >
> > Thanks.
> >
> > I downloaded the most recent from today and tried make all.  It failed
> at some point.  I am attaching the output to help out.  I did ensure that
> the GPR_PROJECT_PATH variable was set.
> >
> > I was confused about the comment you made: "So former makefile couldn't
> work at all for Windows users."  With patches we discussed last month, I
> was able to make Gnoga before, just not out of the box.  The makefile was
> at least functional in Windows using mingw, just some configuration
> problems.  Did you mean something else?
> >
> > Again, thanks for taking a look at this.
> >
> > On Wed, Dec 6, 2017 at 4:29 PM, Pascal via Gnoga-list <
> gnoga-list@lists.sourceforge.net> wrote:
> > Hello,
> >
> > "Reading the manuel always brings you benefit."
> > I has verified that one more time reading in GPRBuild manual how
> GPR_PROJECT_PATH is processed either with UnixLike OS or with Windows.
> > UnixLike, separator is ":", Windows it is ";".
> > So former makefile couldn't work at all for Windows users.
> >
> > Thus I've  made this change and some more to deal with directory paths
> including space character.
> >
> > 1) Now for users who want to use Gnoga as a library, just do:
> > $ make install
> >
> > By default installation is in "inst_folder" in current directory, it can
> be overridden with:
> > $ make PREFIX= install
> >
> > To install also Zanyblue and Pragmarc, you can do before:
> > $ make zanyblue pragmarc
> >
> > I you don't have Sqlite3, you can do before (automatic for Windows):
> > $ make sqlite3
> >
> > And then enjoy, don't forget to set GPR_PROJECT_PATH for your
> installation directory.
> >
> > 2) I you want to play with Gnoga source code, demos, tutorials or even
> tests, do:
> > $ make all
> >
> > And for installation, do:
> > $ make install_debug
> >
> >
> > These changes have been pushed on Gnoga SF GIT branch dev_1.3:
> > https://sourceforge.net/p/gnoga/code/ci/dev_1.3/tree/
> >
> > Could you please test it on your own environnement?
> > Feel free to send feedback.
> >
> > Regards, Pascal.
> > http://blady.pagesperso-orange.fr
> >
> >
> > ---
> ---
> > 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
>
>
> 
> --
> 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
>
--
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

Re: [Gnoga-list] Version 1.3a released and version 1.4-alpha created.

[Jeremiah Breeden]

Thanks.

I downloaded the most recent from today and tried make all.  It failed at
some point.  I am attaching the output to help out.  I did ensure that the
GPR_PROJECT_PATH variable was set.

I was confused about the comment you made: "So former makefile couldn't
work at all for Windows users."  With patches we discussed last month, I
was able to make Gnoga before, just not out of the box.  The makefile was
at least functional in Windows using mingw, just some configuration
problems.  Did you mean something else?

Again, thanks for taking a look at this.

On Wed, Dec 6, 2017 at 4:29 PM, Pascal via Gnoga-list <
gnoga-list@lists.sourceforge.net> wrote:

> Hello,
>
> "Reading the manuel always brings you benefit."
> I has verified that one more time reading in GPRBuild manual how
> GPR_PROJECT_PATH is processed either with UnixLike OS or with Windows.
> UnixLike, separator is ":", Windows it is ";".
> So former makefile couldn't work at all for Windows users.
>
> Thus I've  made this change and some more to deal with directory paths
> including space character.
>
> 1) Now for users who want to use Gnoga as a library, just do:
> $ make install
>
> By default installation is in "inst_folder" in current directory, it can
> be overridden with:
> $ make PREFIX= install
>
> To install also Zanyblue and Pragmarc, you can do before:
> $ make zanyblue pragmarc
>
> I you don't have Sqlite3, you can do before (automatic for Windows):
> $ make sqlite3
>
> And then enjoy, don't forget to set GPR_PROJECT_PATH for your installation
> directory.
>
> 2) I you want to play with Gnoga source code, demos, tutorials or even
> tests, do:
> $ make all
>
> And for installation, do:
> $ make install_debug
>
>
> These changes have been pushed on Gnoga SF GIT branch dev_1.3:
> https://sourceforge.net/p/gnoga/code/ci/dev_1.3/tree/
>
> Could you please test it on your own environnement?
> Feel free to send feedback.
>
> Regards, Pascal.
> http://blady.pagesperso-orange.fr
>
>
>
$ make all
gprbuild -p --target=x86_64-w64-mingw32 -P 
deps/simple_components/lib_components   
 .gpr 
-XAtomic_Access=GCC-long-offsets -XLegacy=Ada2012
object directory 
"D:\Program_Files\msys64\home\Jere\gnoga-code-2017_12_10\deps\s 

   imple_components\obj\components\static\" created
library directory 
"D:\Program_Files\msys64\home\Jere\gnoga-code-2017_12_10\deps\  

  simple_components\lib\components\static" created for project lib_components
gcc -c -g -gnatwcikmoprvz.c.p.t.w.x -gnato -gnatVa -gnatf -g -fstack-check 
-gnat   
 12 parsers-multiline_source-xpm.ads
gcc -c -g -gnatwcikmoprvz.c.p.t.w.x -gnato -gnatVa -gnatf -g -fstack-check 
-gnat12 parsers-generic_source-xpm.adb
parsers-generic_source-xpm.adb:360:10: warning: "Name" is not modified, could 
be declared constant
parsers-generic_source-xpm.adb:496:13: warning: "Name" is not modified, could 
be declared constant
gcc -c -g -gnatwcikmoprvz.c.p.t.w.x -gnato -gnatVa -gnatf -g -fstack-check 
-gnat12 gnat-sockets-server.adb
gcc -c -g -gnatwcikmoprvz.c.p.t.w.x -gnato -gnatVa -gnatf -g -fstack-check 
-gnat12 generic_blackboard.adb
gcc -c -g -gnatwcikmoprvz.c.p.t.w.x -gnato -gnatVa -gnatf -g -fstack-check 
-gnat12 tables.adb
gcc -c -g -gnatwcikmoprvz.c.p.t.w.x -gnato -gnatVa -gnatf -g -fstack-check 
-gnat12 tables-utf8_names.adb
gcc -c -g -gnatwcikmoprvz.c.p.t.w.x -gnato -gnatVa -gnatf -g -fstack-check 
-gnat12 tables-names.adb
gcc -c -g -gnatwcikmoprvz.c.p.t.w.x -gnato -gnatVa -gnatf -g -fstack-check 
-gnat12 synchronization.ads
gcc -c -g -gnatwcikmoprvz.c.p.t.w.x -gnato -gnatVa -gnatf -g -fstack-check 
-gnat12 synchronization-pulse_events.adb
gcc -c -g -gnatwcikmoprvz.c.p.t.w.x -gnato -gnatVa -gnatf -g -fstack-check 
-gnat12 synchronization-mutexes.adb
gcc -c -g -gnatwcikmoprvz.c.p.t.w.x -gnato -gnatVa -gnatf -g -fstack-check 
-gnat12 synchronization-generic_pulse_events.adb
gcc -c -g -gnatwcikmoprvz.c.p.t.w.x -gnato -gnatVa -gnatf -g -fstack-check 
-gnat12 synchronization-generic_mutexes_array.adb
synchronization-generic_mutexes_array.adb:140:23: warning: "Success" modified 
by call, but value might not be referenced
gcc -c -g -gnatwcikmoprvz.c.p.t.w.x -gnato -gnatVa -gnatf -g -fstack-check 
-gnat12 synchronization-generic_events_array.adb
gcc -c -g -gnatwcikmoprvz.c.p.t.w.x -gnato -gnatVa -gnatf -g -fstack-check 
-gnat12 synchronization-events.adb
gcc -c -g -gnatwcikmoprvz.c.p.t.w.x -gnato -gnatVa -gnatf -g -fstack-check 
-gnat12 strings_edit.adb
gcc -c -g -gnatwcikmoprvz.c.p.t.w.x -gnato -gnatVa -gnatf -g -fstack-check 
-gnat12 strings_edit-utf8.adb
gcc -c -g -gnatwcikmoprvz.c.p.t.w.x -gnato -gnatVa -gnatf -g -fstack-check 
-

Re: [Gnoga-list] Version 1.3a released and version 1.4-alpha created.

[Jeremiah Breeden]

My make:

$ make -v
GNU Make 4.2.1
Built for x86_64-pc-msys
Copyright (C) 1988-2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.


On Sun, Nov 5, 2017 at 12:30 PM, Pascal via Gnoga-list <
gnoga-list@lists.sourceforge.net> wrote:

> Hello Jeremiah, see answers below.
> HTH, Pascal.
> http://blady.pagesperso-orange.fr
>
>
> According the (complex) makefiles of Zanyblue, directories should only be
> created if they don't already exist with a rule as for instance:
> $(INSTALL_INCDIR):
> $(call MKDIR,$(INSTALL_INCDIR))
>
> So I wonder about make tool, here is the one I get:
> cmd$ make -v
> GNU Make 3.81
> Copyright (C) 2006  Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.
> There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
> PARTICULAR PURPOSE.
> This program built for i386-apple-darwin11.3.0
>
> What is yours?
>
>
>
--
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

Re: [Gnoga-list] Version 1.3a released and version 1.4-alpha created.

[Jeremiah Breeden]

I'm not sure the correct way to get the version numbers.  I download
snapshots.

The 4/7 one was from the old 1.2 branch.  It lists:
gnoga-code-c1d52b72c56033c328c838b4726a2dd5a019bbf2

the 11/2 one lists:
gnoga-code-bb4b7329fa0674c9a7eabd9c8974c33980ecd1ab

Though recently I was doing git clone and git checkout so I have no idea
how to get the version numbers for those.

On Sun, Nov 5, 2017 at 12:56 PM, Pascal via Gnoga-list <
gnoga-list@lists.sourceforge.net> wrote:

> Hello Jeremiah,
>
> Can precise which version number for both 4/7 and 11/2?
>
> It seems to me a make tool issue.
> I'll ask Zanyblue author what is the configuration used for Windows.
>
> Regards, Pascal.
> http://blady.pagesperso-orange.fr
>
>
> > Le 4 nov. 2017 à 21:20, Jeremiah Breeden  a
> écrit :
> >
> > Ok, some progress.  It looks like for some reason it is picking
> windows_nt.mk in the zanyblue/src/mkfile/ dir instead of unix.mk (for
> mingw64).  The major problem is it wants to use "\" instead of "/" but "\"
> is also an escape character in text strings and certain combinations work
> in commands and others do not.  If I renamed windows_nt.mk to
> windows_nt.old and copied unix.mk to windows_nt.mk
> >
> > For whatever reason the version I downloaded on 4/7/2017 does not have
> this problem.  I don't know if it picks unix.mt or something else occurs,
> but it builds fine with that copy of gnoga.  I found out that the one I
> downloaded on 11/2/2017 (the one I am having problems with) was trying to
> create a home directory in a completely different spot due to the
> windows_nt.mk file command format.  Since it was in the wrong location
> and the commands had "\" in them the build wasn't working correctly.
> >
> > So the question is what changed with zanyblue between 4/7 and 11/2?  I'm
> curious if that was the cause of my "lib" issue earlier.  I'll need to
> start over and check that out.
>
>
> 
> --
> 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
>
--
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

Re: [Gnoga-list] Version 1.3a released and version 1.4-alpha created.

[Jeremiah Breeden]

Responses below

On Sun, Nov 5, 2017 at 1:07 PM, Pascal via Gnoga-list <
gnoga-list@lists.sourceforge.net> wrote:

> Hello Jeremiah,
>
> What is your GNAT version?
>

FSF GNAT 7.2 for mingw64

mingw64 output:
$ GNAT --version
GNAT 7.2.0
Copyright (C) 1996-2017, Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

Target machine:
$ GCC -dumpmachine
x86_64-w64-mingw32



> Could be a system detection issue in GPRBuild?
>
>
I don't know, but I don't feel like it is.  It works well with all other
ada projects.  It is originally targetted for i686-pc-mingw32 but I created
a configuration file (per the gprbuild documentation) and now it retargets
x86_64-w64-mingw32.  If it were a system detection issue inside of
GPRBuild, I would expect all of my ada projects to fail to install or
build.  It only fails when trying to install tools without the exe
extension, but it builds and installs libraries just fine.  That doesn't
rule out a GPRBuild issue, but I don't think it is system detection in
particular.


> HTH, Pascal.
> http://blady.pagesperso-orange.fr
>
>
> > Le 4 nov. 2017 à 21:28, Jeremiah Breeden  a
> écrit :
> >
> > Forgot to add.  So now "make all" works with all the changes I have gone
> through.  The command "make install" still fails as I described in a
> separate email chain a while back (couple of months maybe?).
> >
> > In particular, to get "make install" to work, I have to modify
> tools/tools.gpr and add ".exe" to both executable names:
> >
> >package Builder is
> >   for Executable ("gnoga_make-main.adb") use "gnoga_make.exe";
> >   for Executable ("gnoga_doc-main.adb") use "gnoga_doc.exe";
> >end Builder;
> >
> > Otherwise make install fails with
> > ---
> > Install project Tools
> > file D:\Program_Files\msys64\home\Jere\gnoga-code-2017_11_02\bin\gnoga_make
> does not exist, build may not be complete
> > make: *** [Makefile:202: install] Error 1
> > ---
> >
> > and a similar error for gnoga_doc
> >
>
--
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

Re: [Gnoga-list] Version 1.3a released and version 1.4-alpha created.

[Jeremiah Breeden]

Thanks for the response.  Some responses below.

On Sun, Nov 5, 2017 at 1:24 PM, Pascal via Gnoga-list <
gnoga-list@lists.sourceforge.net> wrote:

> Thanks Jeremiah,
>
> Anyway your feedback is important.
> Your diff file is also important.
> I'll apply the patch for:
> Makefile
> deps/zanyblue/src/zbcom.gpr
> deps/zanyblue/src/zbmcompile/Makefile
>
> Thanks for information below, sorry if I've already asked you them before,
> I read and answer the e-mail one by one.
>
> 1. Seems to me a confusion from make tool between mingw64 and Windows
> systems.
> I'm waiting for Zanyblue answer on Windows building configuration.
>

I would agree, especially with the more recent email.


> 2. Seems to me a GPRBuild issue with Windows.
>
>
Most likely.  I am using the GPRBuild that comes from the Gnoga sourceforge
site.  Unfortunately there aren't any other options out there for 64 bit
windows.  I did ensure that GPRBuild is targetting the correct
platform/architecture.  It works well with all other Ada related projects I
have.
--
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

Re: [Gnoga-list] Version 1.3a released and version 1.4-alpha created.

[Jeremiah Breeden]

Thanks for the feedback!

Perhaps a better question is what is the expected build environment for FSF
based Gnoga on Windows?

By default the command window does not have "make" nor does it have a non
GPL version of GCC.  When you built it, what did you use as an
environment?  I got mingw64 because it comes with both make and FSF GCC.
If there is a different environment that Gnoga requires, I can try to
accomodate.  It might also be good to have something somewhere that lays
out the specific build environment needed since base windows is not
compatible.


On Wed, Nov 8, 2017 at 1:20 PM, Pascal via Gnoga-list <
gnoga-list@lists.sourceforge.net> wrote:

> Hello Jeremiah,
>
> Here is the answer from Zanyblue:
> "The Windows build of ZB is pretty much a Native build, not under a Unix
> style env as supplied by mingw64.  Build in a cmd window is pretty much how
> I verify the build.  It would be possible to detect mingw64 in the build
> process, will investigate however I do expect the a native Windows env.,
> e.g., "\" instead of "/"."
>
> Zanyblue catch the OS environment variable:
> OS=Windows_NT
>
> Here are some build results under cmd window:
>
>
>
> Let me know what you think.
>
> Regards, Pascal.
> http://blady.pagesperso-orange.fr
>
>
> > Le 5 nov. 2017 à 19:24, Pascal via Gnoga-list <
> gnoga-list@lists.sourceforge.net> a écrit :
> >
> > Thanks Jeremiah,
> >
> > Anyway your feedback is important.
> > Your diff file is also important.
> > I'll apply the patch for:
> > Makefile
> > deps/zanyblue/src/zbcom.gpr
> > deps/zanyblue/src/zbmcompile/Makefile
> >
> > Thanks for information below, sorry if I've already asked you them
> before, I read and answer the e-mail one by one.
> >
> > 1. Seems to me a confusion from make tool between mingw64 and Windows
> systems.
> > I'm waiting for Zanyblue answer on Windows building configuration.
> >
> > 2. Seems to me a GPRBuild issue with Windows.
> >
> > Thanks again, Pascal.
> > http://blady.pagesperso-orange.fr
> >
> >
> >> Le 5 nov. 2017 à 15:19, Jeremiah Breeden 
> a écrit :
> >>
> >> Hi,
> >>
> >> The patch partially worked.  It removed all the "make all" errors but
> still had the windows_nt.mk issue which made the "make all" create
> spurious directories outside of the gnoga directory.  It also caused the
> sequence "make all" => "make clean" => "make all" to fail on the second
> "make all" due to some zanyblue conflicts.  "make install" still did not
> work.  I made the two changes I discussed earlier:
> >>
> >> 1.  fix the COPY, MKDIR, RMDIR, and DELETE commands
> >> cd deps/zanyblue/src/mkfile
> >> mv Windows_NT.mk Windows_NT.old
> >> cp unix.mk Windows_NT.mk
> >>
> >> 2.  Fix make install
> >> changed tools/tools.gpr to have ".exe" appended to the executable names.
> >>
> >> I've never made a diff before, so I might have messed this up, but I am
> attaching my updated diff file for reference.
> >>
> >> I don't know if these are good changes, but they are what worked for:
> >> Windows 10 Home
> >> mingw64, gcc 7.2 for x86_64-w64-mingw32
> >> gprbuild from Gnoga sourceforge site.
> >>
> >> They may break things on other platforms or configurations.  And one
> comes involves changing zanyblue files...so not sure how useful this is.
> >>
> >>
> >> On Sat, Nov 4, 2017 at 4:54 PM, Pascal via Gnoga-list <
> gnoga-list@lists.sourceforge.net> wrote:
> >> Hello Jeremiah, see answers below.
> >> HTH, Pascal.
> >> http://blady.pagesperso-orange.fr
>
>
> 
> --
> 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
>
>
--
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

Re: [Gnoga-list] Version 1.3a released and version 1.4-alpha created.

[Jeremiah Breeden]

Hi,

The patch partially worked.  It removed all the "make all" errors but still
had the windows_nt.mk issue which made the "make all" create spurious
directories outside of the gnoga directory.  It also caused the sequence
"make all" => "make clean" => "make all" to fail on the second "make all"
due to some zanyblue conflicts.  "make install" still did not work.  I made
the two changes I discussed earlier:

1.  fix the COPY, MKDIR, RMDIR, and DELETE commands
cd deps/zanyblue/src/mkfile
mv Windows_NT.mk Windows_NT.old
cp unix.mk Windows_NT.mk

2.  Fix make install
changed tools/tools.gpr to have ".exe" appended to the executable names.

I've never made a diff before, so I might have messed this up, but I am
attaching my updated diff file for reference.

I don't know if these are good changes, but they are what worked for:
Windows 10 Home
mingw64, gcc 7.2 for x86_64-w64-mingw32
gprbuild from Gnoga sourceforge site.

They may break things on other platforms or configurations.  And one comes
involves changing zanyblue files...so not sure how useful this is.


On Sat, Nov 4, 2017 at 4:54 PM, Pascal via Gnoga-list <
gnoga-list@lists.sourceforge.net> wrote:

> Hello Jeremiah, see answers below.
> HTH, Pascal.
> http://blady.pagesperso-orange.fr
>
>
>
>
diff --git a/Makefile b/Makefile
index ef21757..3a41ce7 100644
--- a/Makefile
+++ b/Makefile
@@ -132,6 +132,7 @@ simple_components:
$(INSTALLER) --prefix=$(CWD)/build --install-name=components 
deps/simple_components/lib_components.gpr -XAtomic_Access=${ATOMIC_ACCESS} 
-XLegacy=Ada2012
 
 lib/libsqlite3.a:
+   - $(MKDIR) lib
cd deps/simple_components/sqlite-sources && gcc -s -c -O2 -o sqlite3.o 
sqlite3.c
cd deps/simple_components/sqlite-sources && ar rcs libsqlite3.a 
sqlite3.o
cd deps/simple_components/sqlite-sources && $(MOVE) libsqlite3.a 
..$(PATHSEP)..$(PATHSEP)..$(PATHSEP)lib
@@ -141,8 +142,8 @@ sqlite3: lib/libsqlite3.a
 
 # Zanyblue with DEBUG on
 zanyblue:
-   cd deps/zanyblue/src && $(MAKE) BUILD=Debug
-   cd deps/zanyblue/src && $(MAKE) INSTALL_DIR=$(CWD)/build install
+   cd deps/zanyblue/src && $(MAKE) BUILD=Debug APPDIRS="zbmcompile zbinfo"
+   cd deps/zanyblue/src && $(MAKE) INSTALL_DIR=$(CWD)/build 
APPDIRS="zbmcompile zbinfo" install
 
 pragmarc:
$(BUILDER) -P deps/PragmARC/lib_pragmarc.gpr
@@ -197,7 +198,7 @@ release: deps $(BUILD_SQLITE3) setup basic_components
 install: release gnoga_tools
$(INSTALLER) --prefix=$(PREFIX) --install-name=components 
deps/simple_components/lib_components.gpr -XAtomic_Access=${ATOMIC_ACCESS} 
-XLegacy=Ada2012
 # TODO libsqlite3
-   $(MAKE) -C deps/zanyblue/src INSTALL_DIR=$(PREFIX) install
+   $(MAKE) -C deps/zanyblue/src INSTALL_DIR=$(PREFIX) APPDIRS="zbmcompile 
zbinfo" install
$(INSTALLER) --prefix=$(PREFIX) --install-name=pragmarc 
deps/PragmARC/lib_pragmarc.gpr
cd src && $(INSTALLER) --prefix=$(PREFIX) --install-name=gnoga 
gnoga.gpr -XPRJ_BUILD=Release -XPRJ_TARGET=${PRJ_TARGET}
cd tools && $(INSTALLER) --prefix=$(PREFIX) --install-name=gnoga 
--mode=usage tools.gpr -XPRJ_BUILD=Release -XPRJ_TARGET=${PRJ_TARGET}
@@ -206,7 +207,7 @@ install: release gnoga_tools
 install_debug:
$(INSTALLER) --prefix=$(PREFIX) --install-name=components 
deps/simple_components/lib_components.gpr -XAtomic_Access=${ATOMIC_ACCESS} 
-XLegacy=Ada2012
 # TODO libsqlite3
-   $(MAKE) -C deps/zanyblue/src INSTALL_DIR=$(PREFIX) BUILD=Debug install
+   $(MAKE) -C deps/zanyblue/src INSTALL_DIR=$(PREFIX) BUILD=Debug 
APPDIRS="zbmcompile zbinfo" install
$(INSTALLER) --prefix=$(PREFIX) --install-name=pragmarc 
deps/PragmARC/lib_pragmarc.gpr
cd src && $(INSTALLER) --prefix=$(PREFIX) --install-name=gnoga 
gnoga.gpr -XPRJ_TARGET=${PRJ_TARGET}
cd tools && $(INSTALLER) --prefix=$(PREFIX) --install-name=gnoga 
--mode=usage tools.gpr -XPRJ_TARGET=${PRJ_TARGET}
@@ -297,7 +298,7 @@ clean_all: clean clean_deps
 clean_deps:
$(CLEANER) -P deps/simple_components/lib_components.gpr
$(CLEANER) -P deps/PragmARC/lib_pragmarc.gpr
-   cd deps/zanyblue && $(MAKE) -C src clean
+   cd deps/zanyblue && $(MAKE) -C src APPDIRS="zbmcompile zbinfo" clean
$(RMS) build
cd deps && $(RMS) MultiMarkdown-4
cd deps && $(RMS) electron-quick-start
diff --git a/deps/zanyblue/src/mkfile/Windows_NT.mk 
b/deps/zanyblue/src/mkfile/Windows_NT.mk
index c9a3d6e..5bf39ca 100644
--- a/deps/zanyblue/src/mkfile/Windows_NT.mk
+++ b/deps/zanyblue/src/mkfile/Windows_NT.mk
@@ -1,67 +1,74 @@
-#  -*- coding: utf-8 -*-
-#
-#  ZanyBlue, an Ada library and framework for finite element analysis.
-#
-#  Copyright (c) 2012, 2016, Michael Rohan 
-#  All rights reserved.
-#
-#  Redistribution and use in source and binary forms, with or without
-#  modification, are permitted provided that the following conditions
-#  are met:
-#
-#* Redistributions of source code must retain the above copyright
-#  notice, this 

Re: [Gnoga-list] Version 1.3a released and version 1.4-alpha created.

[Jeremiah Breeden]

Forgot to add.  So now "make all" works with all the changes I have gone
through.  The command "make install" still fails as I described in a
separate email chain a while back (couple of months maybe?).

In particular, to get "make install" to work, I have to modify
tools/tools.gpr and add ".exe" to both executable names:

   package Builder is
  for Executable ("gnoga_make-main.adb") use "gnoga_make.exe";
  for Executable ("gnoga_doc-main.adb") use "gnoga_doc.exe";
   end Builder;

Otherwise make install fails with
---
Install project Tools
file D:\Program_Files\msys64\home\Jere\gnoga-code-2017_11_02\bin\gnoga_make
does not exist, build may not be complete
make: *** [Makefile:202: install] Error 1
---

and a similar error for gnoga_doc

On Sat, Nov 4, 2017 at 4:20 PM, Jeremiah Breeden  wrote:

> Ok, some progress.  It looks like for some reason it is picking
> windows_nt.mk in the zanyblue/src/mkfile/ dir instead of unix.mk (for
> mingw64).  The major problem is it wants to use "\" instead of "/" but "\"
> is also an escape character in text strings and certain combinations work
> in commands and others do not.  If I renamed windows_nt.mk to
> windows_nt.old and copied unix.mk to windows_nt.mk
>
> For whatever reason the version I downloaded on 4/7/2017 does not have
> this problem.  I don't know if it picks unix.mt or something else occurs,
> but it builds fine with that copy of gnoga.  I found out that the one I
> downloaded on 11/2/2017 (the one I am having problems with) was trying to
> create a home directory in a completely different spot due to the
> windows_nt.mk file command format.  Since it was in the wrong location
> and the commands had "\" in them the build wasn't working correctly.
>
> So the question is what changed with zanyblue between 4/7 and 11/2?  I'm
> curious if that was the cause of my "lib" issue earlier.  I'll need to
> start over and check that out.
>
>
--
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

Re: [Gnoga-list] Version 1.3a released and version 1.4-alpha created.

[Jeremiah Breeden]

Ok, some progress.  It looks like for some reason it is picking
windows_nt.mk in the zanyblue/src/mkfile/ dir instead of unix.mk (for
mingw64).  The major problem is it wants to use "\" instead of "/" but "\"
is also an escape character in text strings and certain combinations work
in commands and others do not.  If I renamed windows_nt.mk to
windows_nt.old and copied unix.mk to windows_nt.mk

For whatever reason the version I downloaded on 4/7/2017 does not have this
problem.  I don't know if it picks unix.mt or something else occurs, but it
builds fine with that copy of gnoga.  I found out that the one I downloaded
on 11/2/2017 (the one I am having problems with) was trying to create a
home directory in a completely different spot due to the windows_nt.mk file
command format.  Since it was in the wrong location and the commands had
"\" in them the build wasn't working correctly.

So the question is what changed with zanyblue between 4/7 and 11/2?  I'm
curious if that was the cause of my "lib" issue earlier.  I'll need to
start over and check that out.

On Sat, Nov 4, 2017 at 3:44 PM, Jeremiah Breeden  wrote:

> I tried your makefile change but it didn't work.  I did what Jeff Carter
> suggested and got through that step but now I am failing on:
>
> 
> -
> cmd.exe /c "mkdir \home\Jere\gnoga-code-2017_11_02\build\lib\gnat"
> A subdirectory or file \home\Jere\gnoga-code-2017_11_02\build\lib\gnat
> already exists.
> make[1]: *** [../src/mkfile/install.mk:93: /home/Jere/gnoga-code-2017_11_
> 02/build/lib/gnat/zanyblue.gpr] Error 1
> make[1]: Leaving directory '/home/Jere/gnoga-code-2017_
> 11_02/deps/zanyblue/src'
> make: *** [Makefile:145: zanyblue] Error 2
> 
> -
>
> I had similar errors for
> \home\Jere\gnoga-code-2017_11_02\build\lib\zanyblue
> and
> \home\Jere\gnoga-code-2017_11_02\build\include\zanyblue
>
> Adding the directories for those last two seemed to placate the make
> (though counter intuitive since the directories didn't exist), however that
> last one does not go away.  Did something change in Zanyblue?  These type
> of errors are new to me.
>
> Just trying the command:   cmd.exe /c "mkdir \home\Jere\gnoga-code-2017_11_
> 02\build\lib\gnat"
>
> manually leads to the same error.  I think it is a poorly formed command
> for windows (the \ is probably interpreted as an escape)?  The directory
> isn't actually there but it thinks it is for some reason.
>
> Using unix style slashes makes the command work (manually) in mingw64.  I
> have no clue how it works in cygwin.  I don't, however, know how to fix the
> zanyblue compilation to use unix slashes instead.
>
> So right now I am dead in the water for building until I can figure this
> part out.  Still looking around though.
>
>
> On Sat, Nov 4, 2017 at 5:50 AM, Pascal via Gnoga-list <
> gnoga-list@lists.sourceforge.net> wrote:
>
>> Thanks Jeremiah for reporting.
>>
>> See some answers below.
>> But in a general case,I need more information on what happened, can you
>> send attached full log?
>>
>> Regards, Pascal.
>> http://blady.pagesperso-orange.fr
>>
>>
>> > Le 3 nov. 2017 à 01:02, Jeremiah Breeden 
>> a écrit :
>> >
>> > Right now there are a lot of issues compiling with the following setup:
>> >
>> > Windows 10 64 bit
>> > mingw64 (GCC 7.2)
>> > "make all" command
>> >
>> > Issues so far:
>> > 
>>
>> >
>> > 4.  zbtest failed to compile due to no xmlada library.  I stopped
>> here.  Prior to 1.3 I was able to do make all with this setup no problem.
>> I'm guessing xmlada is a new dependency?  Or perhaps the make file used to
>> ignore?  not sure what to do here.
>>
>> XMLAda lib is a default lib for GNAT GPL. I missed that. As zbtest is not
>> required for you, you can omit it:
>> Gnoga Makefile change:
>>
>> # Zanyblue with DEBUG on
>> zanyblue:
>> -   cd deps/zanyblue/src && $(MAKE) BUILD=Debug
>> +   cd deps/zanyblue/src && $(MAKE) BUILD=Debug APPDIRS="zbmcompile
>> zbinfo"
>> cd deps/zanyblue/src && $(MAKE) INSTALL_DIR=$(CWD)/build install
>>
>>
>>
>
--
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

Re: [Gnoga-list] Version 1.3a released and version 1.4-alpha created.

[Jeremiah Breeden]

I tried your makefile change but it didn't work.  I did what Jeff Carter
suggested and got through that step but now I am failing on:

-
cmd.exe /c "mkdir \home\Jere\gnoga-code-2017_11_02\build\lib\gnat"
A subdirectory or file \home\Jere\gnoga-code-2017_11_02\build\lib\gnat
already exists.
make[1]: *** [../src/mkfile/install.mk:93:
/home/Jere/gnoga-code-2017_11_02/build/lib/gnat/zanyblue.gpr] Error 1
make[1]: Leaving directory
'/home/Jere/gnoga-code-2017_11_02/deps/zanyblue/src'
make: *** [Makefile:145: zanyblue] Error 2
-

I had similar errors for
\home\Jere\gnoga-code-2017_11_02\build\lib\zanyblue
and
\home\Jere\gnoga-code-2017_11_02\build\include\zanyblue

Adding the directories for those last two seemed to placate the make
(though counter intuitive since the directories didn't exist), however that
last one does not go away.  Did something change in Zanyblue?  These type
of errors are new to me.

Just trying the command:   cmd.exe /c "mkdir
\home\Jere\gnoga-code-2017_11_02\build\lib\gnat"

manually leads to the same error.  I think it is a poorly formed command
for windows (the \ is probably interpreted as an escape)?  The directory
isn't actually there but it thinks it is for some reason.

Using unix style slashes makes the command work (manually) in mingw64.  I
have no clue how it works in cygwin.  I don't, however, know how to fix the
zanyblue compilation to use unix slashes instead.

So right now I am dead in the water for building until I can figure this
part out.  Still looking around though.


On Sat, Nov 4, 2017 at 5:50 AM, Pascal via Gnoga-list <
gnoga-list@lists.sourceforge.net> wrote:

> Thanks Jeremiah for reporting.
>
> See some answers below.
> But in a general case,I need more information on what happened, can you
> send attached full log?
>
> Regards, Pascal.
> http://blady.pagesperso-orange.fr
>
>
> > Le 3 nov. 2017 à 01:02, Jeremiah Breeden  a
> écrit :
> >
> > Right now there are a lot of issues compiling with the following setup:
> >
> > Windows 10 64 bit
> > mingw64 (GCC 7.2)
> > "make all" command
> >
> > Issues so far:
> > 
>
> >
> > 4.  zbtest failed to compile due to no xmlada library.  I stopped here.
> Prior to 1.3 I was able to do make all with this setup no problem.  I'm
> guessing xmlada is a new dependency?  Or perhaps the make file used to
> ignore?  not sure what to do here.
>
> XMLAda lib is a default lib for GNAT GPL. I missed that. As zbtest is not
> required for you, you can omit it:
> Gnoga Makefile change:
>
> # Zanyblue with DEBUG on
> zanyblue:
> -   cd deps/zanyblue/src && $(MAKE) BUILD=Debug
> +   cd deps/zanyblue/src && $(MAKE) BUILD=Debug APPDIRS="zbmcompile
> zbinfo"
> cd deps/zanyblue/src && $(MAKE) INSTALL_DIR=$(CWD)/build install
>
>
>
--
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

Re: [Gnoga-list] Version 1.3a released and version 1.4-alpha created.

[Jeremiah Breeden]

Thanks for the reply.  Individual responses below.  Note that both the -g
switch and bin folder issues have existed in Gnoga for a long time.  I've
mentioned them before but figured since I was reporting back on other
issues to include them.

On Sat, Nov 4, 2017 at 5:50 AM, Pascal via Gnoga-list <
gnoga-list@lists.sourceforge.net> wrote:

> Thanks Jeremiah for reporting.
>
> 
>
> Seems that starting with a fresh empty working directory is needed in this
> case then clone, checkout and make all.
>
>
Well I always start with a fresh directory.  I get the .zip from
sourceforge, extract it to a new folder, move the old folder into my __old
directory, and then move in the new gnoga folder I just made.  Then I open
up mingw64, cd to my new gnoga directory and do make all.  I attached a
file, lib_issue.txt, to show the output.  The fix is to delete the file
named "lib" (it is created by gnoga's make all command..verified that), and
manually create a lib directory in the top level of my gnoga folder.


> >
> > 2.  zbcom fails to build due to warnings treated as errors.  I removed
> the -g switch from zbcom.gpr to continue
>
> What were the warnings?
> What about -g switch?
>

After the fix for the lib, I run the make all. I attached a file,
warnings_issue.txt, to illustrate.  The fix is to go into zbcom.gpr and
change one of the switches not to use -g.  Specifically:
-gnatygO

is changed to

-gnatyO

I don't know if this is a good long term fix, but it gets the make going
again.


> >
> > 3.  zbcomile fails because it cannot create the bin folder in zanyblue.
> I manually added the binf file to continue
>
> Maybe same as point 1.
>

I attached a file, bin_issue.txt, with the output.  Here, gnoga cannot
create a bin folder in  deps/zanyblue/
If I add the folder manually, the make can continue.  Note that windows 10
cannot use chmod to modify permissions it seems (tried that first).  The
commond in mingw exists but doesn't fully work.


> >
> > 4.  zbtest failed to compile due to no xmlada library.  I stopped here.
> Prior to 1.3 I was able to do make all with this setup no problem.  I'm
> guessing xmlada is a new dependency?  Or perhaps the make file used to
> ignore?  not sure what to do here.
>
> XMLAda lib is a default lib for GNAT GPL. I missed that. As zbtest is not
> required for you, you can omit it:
> Gnoga Makefile change:
>
> # Zanyblue with DEBUG on
> zanyblue:
> -   cd deps/zanyblue/src && $(MAKE) BUILD=Debug
> +   cd deps/zanyblue/src && $(MAKE) BUILD=Debug APPDIRS="zbmcompile
> zbinfo"
> cd deps/zanyblue/src && $(MAKE) INSTALL_DIR=$(CWD)/build install
>

I'll try that out and get back with you.


> >
> > Right now, using Gnoga with FSF GNAT on windows has a lot of speed
> bumps.  For now I am reverting back to 1.2 until I can figure it out.
>
> Sorry for that, 1.3 is really worth while as it includes modal dialogs ;-)
>

Sorry, that sounded harsher than I meant.  I just meant that since I cannot
build gnoga for 1.3 yet I have to revert to 1.2 in my build environment
until I figure it out.  I still plan on trying to get gnoga to build for
1.3...just had to shelve it for a day or two.
$ make all
gprbuild -p --target=x86_64-w64-mingw32 -P 
deps/simple_components/lib_components.gpr -XAtomic_Access=GCC-long-offsets 
-XLegacy=Ada2012
"libcomponents.a" up to date
gprinstall -p -f --target=x86_64-w64-mingw32 
--prefix=/home/Jere/gnoga-code-2017_11_02/build --install-name=components 
deps/simple_components/lib_components.gpr -XAtomic_Access=GCC-long-offsets 
-XLegacy=Ada2012
Install project Lib_Components
warning: path does not exist 
'd:\program_files\msys64\home\jere\gnoga-code-2017_11_02\deps\simple_components\obj/components/static/gnatdoc/'
make -C src
make[1]: Entering directory '/home/Jere/gnoga-code-2017_11_02/src'
make[1]: Nothing to be done for 'all'.
make[1]: Leaving directory '/home/Jere/gnoga-code-2017_11_02/src'
make -C components
make[1]: Entering directory '/home/Jere/gnoga-code-2017_11_02/components'
make -C bootstrap install
make[2]: Entering directory 
'/home/Jere/gnoga-code-2017_11_02/components/bootstrap'
cp -p src/*.* ../../src
cp -p css/*.* ../../css
cp -p html/*.* ../../html
mkdir ../../html/fonts
mkdir: cannot create directory ‘../../html/fonts’: File exists
make[2]: [Makefile:19: install] Error 1 (ignored)
cp -p html/fonts/*.* ../../html/fonts
cp -p js/*.* ../../js
make[2]: Leaving directory 
'/home/Jere/gnoga-code-2017_11_02/components/bootstrap'
make -C jqueryui install
make[2]: Entering directory 
'/home/Jere/gnoga-code-2017_11_02/components/jqueryui'
cp -p src/*.* ../../src
cp -p css/*.* ../../css
cp -p html/*.* ../../html
mkdir ../../css/images
mkdir: cannot create directory ‘../../css/images’: File exists
make[2]: [Makefile:19: install] Error 1 (ignored)
cp -p css/images/*.* ../../css/images
cp -p js/*.* ../../js
make[2]: Leaving directory 
'/home/Jere/gnoga-code-2017_11_02/components/jqueryui'
make -C message_boxes install
make[2]: Entering directory 
'/home/Jere

Re: [Gnoga-list] Version 1.3a released and version 1.4-alpha created.

[Jeremiah Breeden]

Ugg...I must have been tired last night.

For #3 I meant zbcompile fails and that I manually added the bin folder

On Thu, Nov 2, 2017 at 8:02 PM, Jeremiah Breeden  wrote:

> Right now there are a lot of issues compiling with the following setup:
>
> Windows 10 64 bit
> mingw64 (GCC 7.2)
> "make all" command
>
> Issues so far:
> 1.  fails to compile because it cannot make the ./lib directory.  When I
> looked at the directory structure there existed a file named "lib" with no
> extension.  Windows cannot have both a file and a directory named lib.  I
> deleted the file to continue
>
> 2.  zbcom fails to build due to warnings treated as errors.  I removed the
> -g switch from zbcom.gpr to continue
>
> 3.  zbcomile fails because it cannot create the bin folder in zanyblue.  I
> manually added the binf file to continue
>
> 4.  zbtest failed to compile due to no xmlada library.  I stopped here.
> Prior to 1.3 I was able to do make all with this setup no problem.  I'm
> guessing xmlada is a new dependency?  Or perhaps the make file used to
> ignore?  not sure what to do here.
>
> Right now, using Gnoga with FSF GNAT on windows has a lot of speed bumps.
> For now I am reverting back to 1.2 until I can figure it out.
>
> Anyone else having similar problems?
>
>
> On Wed, Nov 1, 2017 at 6:40 AM, Pascal via Gnoga-list <
> gnoga-list@lists.sourceforge.net> wrote:
>
>> Hello,
>>
>> Version 1.3a has been released on SF GIT dev_1.3 branch.
>> https://sourceforge.net/p/gnoga/code/ci/dev_1.3/tree/
>>
>> See HISTORY for details.
>>
>> This branch is now the default one.
>>
>> Source code has been zipped (gnoga-1.3a.zip) available on:
>> https://sourceforge.net/projects/gnoga/files/
>>
>> Then new branch dev_1.4 has been created to collect new developments, see
>> TODO:
>> https://sourceforge.net/p/gnoga/code/ci/dev_1.3/tree/TODO
>>
>> Feel free to report detailed issues on this list or create tickets on SF:
>> https://sourceforge.net/p/gnoga/mailman/
>> https://sourceforge.net/p/gnoga/tickets/
>>
>> Regards, Pascal.
>> http://blady.pagesperso-orange.fr
>>
>>
>>
>> 
>> --
>> 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
>>
>
>
--
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

Re: [Gnoga-list] Version 1.3a released and version 1.4-alpha created.

[Jeremiah Breeden]

Forgot to add I manually created the lib directory afterwards as well.

On Thu, Nov 2, 2017 at 8:02 PM, Jeremiah Breeden  wrote:

> 1.  fails to compile because it cannot make the ./lib directory.  When I
> looked at the directory structure there existed a file named "lib" with no
> extension.  Windows cannot have both a file and a directory named lib.  I
> deleted the file to continue
>
--
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

Re: [Gnoga-list] Version 1.3a released and version 1.4-alpha created.

[Jeremiah Breeden]

I missed an earlier email.  Seems like the xml ada thing is already being
discussed.

On Thu, Nov 2, 2017 at 8:02 PM, Jeremiah Breeden  wrote:

> Right now there are a lot of issues compiling with the following setup:
>
> 
>
> 4.  zbtest failed to compile due to no xmlada library.  I stopped here.
> Prior to 1.3 I was able to do make all with this setup no problem.  I'm
> guessing xmlada is a new dependency?  Or perhaps the make file used to
> ignore?  not sure what to do here.
>
>
>
--
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

Re: [Gnoga-list] Version 1.3a released and version 1.4-alpha created.

[Jeremiah Breeden]

Right now there are a lot of issues compiling with the following setup:

Windows 10 64 bit
mingw64 (GCC 7.2)
"make all" command

Issues so far:
1.  fails to compile because it cannot make the ./lib directory.  When I
looked at the directory structure there existed a file named "lib" with no
extension.  Windows cannot have both a file and a directory named lib.  I
deleted the file to continue

2.  zbcom fails to build due to warnings treated as errors.  I removed the
-g switch from zbcom.gpr to continue

3.  zbcomile fails because it cannot create the bin folder in zanyblue.  I
manually added the binf file to continue

4.  zbtest failed to compile due to no xmlada library.  I stopped here.
Prior to 1.3 I was able to do make all with this setup no problem.  I'm
guessing xmlada is a new dependency?  Or perhaps the make file used to
ignore?  not sure what to do here.

Right now, using Gnoga with FSF GNAT on windows has a lot of speed bumps.
For now I am reverting back to 1.2 until I can figure it out.

Anyone else having similar problems?


On Wed, Nov 1, 2017 at 6:40 AM, Pascal via Gnoga-list <
gnoga-list@lists.sourceforge.net> wrote:

> Hello,
>
> Version 1.3a has been released on SF GIT dev_1.3 branch.
> https://sourceforge.net/p/gnoga/code/ci/dev_1.3/tree/
>
> See HISTORY for details.
>
> This branch is now the default one.
>
> Source code has been zipped (gnoga-1.3a.zip) available on:
> https://sourceforge.net/projects/gnoga/files/
>
> Then new branch dev_1.4 has been created to collect new developments, see
> TODO:
> https://sourceforge.net/p/gnoga/code/ci/dev_1.3/tree/TODO
>
> Feel free to report detailed issues on this list or create tickets on SF:
> https://sourceforge.net/p/gnoga/mailman/
> https://sourceforge.net/p/gnoga/tickets/
>
> Regards, Pascal.
> http://blady.pagesperso-orange.fr
>
>
>
> 
> --
> 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
>
--
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

Re: [Gnoga-list] Is it reasonable to request project file changes for some environment configurations?

[Jeremiah Breeden]

Just wanted to touch base again.  Is this something that I can generate a
ticket for (I will if so) or is it too constrained to a particular setup?
I can't test on mac or linux to see if there are any impacs, so I this
might be a concern.

As far as I know there aren't a lot of available windows 64 bit
configurations that allow for the building of Gnoga.  mingw64 is the only
one I got to work and I had to really man handle gprbuild to get it to work.

On Tue, Aug 29, 2017 at 11:56 AM, Jeremiah Breeden <
jeremiah.bree...@gmail.com> wrote:

> So I finally got a windows 10 non GPL gnoga environment build and working
> (at least so far).  However, in order to build gnoga I had to make some
> changes to a couple of the GPR files or else the "make install" command
> would fail horribly.
>
> For some reason both tools.gpr and zbmcompile.gpr would fail to install at
> all at first.  They are both unique in that instead of installing a
> library, they install executables into /bin.  So I am assuming that is the
> reason those two failed while the others installed fine.
>
> The error in question was something like:
>
> /some_path/gnoga_make does not exist (it was there, I checked to make sure)
>
> I added a .exe extension to the parts that specified the executable name:
>
> tools.gpr
> *
>
>package Builder is
>   for Executable ("gnoga_make-main.adb") use "gnoga_make";
>   for Executable ("gnoga_doc-main.adb") use "gnoga_doc";
>end Builder;
>
> *
>
> became:
> *
>
>package Builder is
>   for Executable ("gnoga_make-main.adb") use "gnoga_make.exe";
>   for Executable ("gnoga_doc-main.adb") use "gnoga_doc.exe";
>end Builder;
>
> *
>
> zbmcompile.gpr
> *
>
>package Builder is
>   for Executable ("zbmcompile-main.adb") use "zbmcompile";
>end Builder;
>
> *
>
> became:
> *
>
>package Builder is
>   for Executable ("zbmcompile-main.adb") use "zbmcompile.exe";
>end Builder;
>
> *
>
>
> I realize that this is a fix specific for FSF gnat compilation of gnoga on
> windows for mingw64, but was curious if it was still reasonable to ask that
> the library be updated with these changes or if that was just out of
> scope.  Obviously someone would want to test on a linux distro to ensure
> nothing gets broken.  I don't have one to test on.
>
>
--
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

Re: [Gnoga-list] Specifying Source for Audio_Type

[Jeremiah Breeden]

I tried this on windows and I couldn't even get it to play in the gpr or
executable directory (the base directory).  I tried with both firefox and
IE.

On Fri, Sep 15, 2017 at 8:00 AM, Jeffrey R. Carter  wrote:

> I have this tiny Gnoga app:
>
> with Ada.Exceptions;
>
> with Gnoga.Application.Singleton;
> with Gnoga.Gui.Base;
> with Gnoga.Gui.Element.Common;
> with Gnoga.Gui.Element.Multimedia;
> with Gnoga.Gui.View;
> with Gnoga.Gui.Window;
>
> package body MP.UI is
>Window : Gnoga.Gui.Window.Window_Type;
>View   : Gnoga.Gui.View.View_Type;
>Player : Gnoga.Gui.Element.Multimedia.Audio_Type;
>Quit   : Gnoga.Gui.Element.Common.Button_Type;
>
>procedure Quit_Now (Object : in out Gnoga.Gui.Base.Base_Type'Class) is
>   -- Empty;
>begin -- Quit_Now
>   Gnoga.Application.Singleton.End_Application;
>exception -- Quit_Now
>when E : others =>
>   Gnoga.Log (Message => "Quit_Now: " & 
> Ada.Exceptions.Exception_Information
> (E) );
>end Quit_Now;
> begin -- MP.UI
>Gnoga.Application.Title ("MP");
>Gnoga.Application.HTML_On_Close ("MP ended.");
>Gnoga.Application.Open_URL;
>Gnoga.Application.Singleton.Initialize (Main_Window => Window);
>View.Create (Parent => Window);
>Player.Create (Parent => View, Source => "glass.ogg", Preload => True);
>Gnoga.Log(Player.Media_Source);
>View.New_Line;
>Quit.Create (Parent => View, Content => "Quit");
>Quit.On_Click_Handler (Handler => Quit_Now'Access);
>Gnoga.Application.Singleton.Message_Loop;
> exception -- MP.UI
> when E : others =>
>Gnoga.Log (Message => Ada.Exceptions.Exception_Information (E) );
> end MP.UI;
>
> which works fine and reports the source as "http://127.0.0.1:8080/glass.
> ogg".
> However, if I want to access a file not in the current directory, I have
> problems. Using "~/Code/Chattanooga/glass.ogg" results in the widget not
> being
> shown, and the source as "http://127.0.0.1:8080/~/Code/
> Chattanooga/glass.ogg".
> "/home/jrcarter/Code/Chattanooga/glass.ogg" also results in the widget
> not being
> shown and the source as
> "http://127.0.0.1:8080/home/jrcarter/Code/Chattanooga/glass.ogg";.
> "file:///home/jrcarter/Code/Chattanooga/glass.ogg" results in the widget
> being
> shown, but nothing plays, with the reported source also being
> "file:///home/jrcarter/Code/Chattanooga/glass.ogg".
>
> The file exists:
>
> $ ll /home/jrcarter/Code/Chattanooga/glass.ogg
> -rw-r--r-- 1 jrcarter jrcarter 18999 Jan 11  2015 /home/jrcarter/Code/
> Chattanooga/glass.ogg
>
> How can I play a file not in the current directory?
>
> --
> Jeff Carter
>
--
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

[Gnoga-list] Is it reasonable to request project file changes for some environment configurations?

[Jeremiah Breeden]

So I finally got a windows 10 non GPL gnoga environment build and working
(at least so far).  However, in order to build gnoga I had to make some
changes to a couple of the GPR files or else the "make install" command
would fail horribly.

For some reason both tools.gpr and zbmcompile.gpr would fail to install at
all at first.  They are both unique in that instead of installing a
library, they install executables into /bin.  So I am assuming that is the
reason those two failed while the others installed fine.

The error in question was something like:

/some_path/gnoga_make does not exist (it was there, I checked to make sure)

I added a .exe extension to the parts that specified the executable name:

tools.gpr
*

   package Builder is
  for Executable ("gnoga_make-main.adb") use "gnoga_make";
  for Executable ("gnoga_doc-main.adb") use "gnoga_doc";
   end Builder;

*

became:
*

   package Builder is
  for Executable ("gnoga_make-main.adb") use "gnoga_make.exe";
  for Executable ("gnoga_doc-main.adb") use "gnoga_doc.exe";
   end Builder;

*

zbmcompile.gpr
*

   package Builder is
  for Executable ("zbmcompile-main.adb") use "zbmcompile";
   end Builder;

*

became:
*

   package Builder is
  for Executable ("zbmcompile-main.adb") use "zbmcompile.exe";
   end Builder;

*


I realize that this is a fix specific for FSF gnat compilation of gnoga on
windows for mingw64, but was curious if it was still reasonable to ask that
the library be updated with these changes or if that was just out of
scope.  Obviously someone would want to test on a linux distro to ensure
nothing gets broken.  I don't have one to test on.
--
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

Re: [Gnoga-list] Question: Protected data and user disconnection interaction (Gnoga)

[Jeremiah Breeden]

I spent some time looking through the RM, but was unable to find a section
detailing what is supposed to happen when dereferencing a dangling access.
My assumption is that it is erroneous behavior that may or may not result
into an exception since the access is not null but was deallocated after it
was copied to the return value in your example.

I would suggest you look wrapping the record data with more protection.
Some sort of protected action that prevents it from being deallocated until
the current operation is finished and detects if it has been deallocated
before performing an operation (and throwing an exception).  This way you
are in control of what happens.  You can catch the exception (which you
know will always occur since you coded it to do so) and handle it
gracefully.  This might mean that you cannot use it as an access type
directly, so it might require redesign.

On Mon, Jul 31, 2017 at 1:45 PM, Olivier Henley wrote:

> *Rebooting a question because I received no feedback; did original post a
> month ago.
>
> Using Gnoga for a multiplayer game, I have a question which I fail to
> answer myself because I do not know a) enough about Ada and b) enough about
> the architecture of Gnoga/Simple Components stack.
>
> - note1: A match is two players connected through webRTC.
> - note2: To establish a webRTC connection between those two players I have
> to relay some messages to one another, without delay.
>
> This sample code is a subset of what I have done to relay messages from
> one player to the other. My question is about the eventual outcome of one
> player disconnecting while Relaying. Let suppose the 'other' player is
> killing its browser.
> 
>
> procedure Relay_Signal (App_Data : in App_Data_Access; Value : String) is
>   Other_App_Data : App_Data_Access := Control.Find_Other(App_Data);
> begin
>   if Other_App_Data /= null then
>  My_Game.Controller.Relay_Message(Other_App_Data, Value);
>   end if;
> end Relay_Signal;
>
> protected Control is
>   function Find_Other (App_Data : App_Data_Access) return
> App_Data_Access;
> private
>   Matchs : Matchs_Vec.Vector;
> end Control;
>
> protected body Control is
>
>   function Find_Other (App_Data : App_Data_Access) return
> App_Data_Access is
>   begin
>  if App_Data.Match_Index_Is_Valid then
> for Player of Matchs.Element(App_Data.Match_Index).Players
> loop
>if Player /= App_Data then
>   return Player;
>end if;
> end loop;
>  end if;
>  return null;
>   end Find_Other;
>
> end Control;
>
> -
>
> I suppose that in the worst case: Other_App_Data is found and returned
> from Find_Other but that other player is disconnected (Other_App_Data
> becomes invalid) just before My_Game.Controller.Relay_Message(Other_App_Data,
> Value) is called. What I think will happen is just an exception thrown when
> I am manipulating Other_App_Data inside Relay_Message.
>
> 1) Am I right? If so is it OK?
> 2) Else, why and how should I handle such a case?
>
> Thx,
>
> Olivier
> 
>
--
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

Re: [Gnoga-list] Modal dialog box

[Jeremiah Breeden]

On Wed, Jun 28, 2017 at 2:26 PM, Pascal via Gnoga-list <
gnoga-list@lists.sourceforge.net> wrote:

> Hello Jeremiah,
>
> > Le 25 juin 2017 à 16:45, Jeremiah Breeden 
> a écrit :
> >
> > Sorry for the lateness of this.  My kids have been keeping me busy as of
> late.  Attached are both versions.  I tested compilation by adding them to
> my local Gnoga library and using "make gnoga".  I tested functionality in
> various of my smaller projects (I'll attach a test program I used, but it
> isn't gnoga style compliant).  That said, I don't know how bullet proof
> they are yet.  If I had more time, I would have generated a lot of tests.
> To run my test program simply call it in your On_Connect handler ina
> multiconnect gnoga program like this:
> >
> >procedure On_Connect
> >   (Main_Window : in out Gnoga.Gui.Window.Window_Type'Class;
> >Connection  : access
> >   Gnoga.Application.Multi_Connect.Connection_Holder_Type)
> >is
> >begin
> >   Test_Dialog.On_Connect(Main_Window,Connection);
> >end On_Connect;
> >
> >
> > Tested in Windows 10, GNAT GPL 2016, Firefox (current version)
>
> Thanks again for your contribution, however I prefer add a standalone test
> program than a package as it is easier to build and run.
> Here is the one I've made from your test package:
>
>
> Is it correct for you ?
>

This works for me.  Thanks.

>
> >
> > >procedure Remove (Dialog : in out Dialog_Type);
> > >--  Removes an element from the DOM, if the ID_Type is DOM_ID, the
> ID
> >
> > Removes the dialog?
> >
> > Yes, this maybe overkill.  It cannot be dynamically managed in version 2
> but you can still remove it from the DOM (if I did it correctly) in cases
> where you want to manually manage stuff.  Kind of a compromise.  any of
> this stuff is up for debate/removal.
>
> In fact, I was pointing the comment, Shouldn't it be "--  Removes dialog
> from the DOM..."?
>

I used the same comment found in the Gnoga library for consistency.
Normally when I override something, I try to do that so it makes someone
look closer.  I don't mind if you want to change it though.
--
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

Re: [Gnoga-list] Modal dialog box

[Jeremiah Breeden]

Sorry for the lateness of this.  My kids have been keeping me busy as of
late.  Attached are both versions.  I tested compilation by adding them to
my local Gnoga library and using "make gnoga".  I tested functionality in
various of my smaller projects (I'll attach a test program I used, but it
isn't gnoga style compliant).  That said, I don't know how bullet proof
they are yet.  If I had more time, I would have generated a lot of tests.
To run my test program simply call it in your On_Connect handler ina
multiconnect gnoga program like this:

   procedure On_Connect
  (Main_Window : in out Gnoga.Gui.Window.Window_Type'Class;
   Connection  : access
  Gnoga.Application.Multi_Connect.Connection_Holder_Type)
   is
   begin
  Test_Dialog.On_Connect(Main_Window,Connection);
   end On_Connect;


Tested in Windows 10, GNAT GPL 2016, Firefox (current version)


On Sat, Jun 3, 2017 at 7:08 AM, Pascal  wrote:

> Hello Jeremiah,
>
> > Side question:  how do I handle the copyright notice in the top of the
> files.  David holds copyright over Gnoga.  Since this is an extension, do I
> put my name in the copyright or his or both?
>
> Yes, since this is a contribution of new source code files from yours
> included in Gnoga.
>
You answered with a yes to a multiple option question, so I may have
misinterpreted, but I think your intent was the "yes" for me putting my
name with the copyright notice.  I did that.  If we need to put David's
name in, feel free to update that.  I'm not very good with this type of
stuff.


> >procedure Create
> >   (Dialog : in out Dialog_Type;
> >Parent : in out Gnoga.Gui.View.View_Base_Type'Class;
> >ID : in String := "");
> >--  Create a modal dialog using a view as the parent
>
> Is it desired to have a modal dialog as child of one view of the window
> since the window can hold several views.
> In my understanding, modal dialog is expected blocking for the whole
> window, isn't it?
>

In general, yes, it usually only blocks the window.  I had one test case (
a mini ide type mockup) where I wanted the dialog to block a cell in a grid
view only, so that is what that is for.  Again, not extensively tested, but
it works in my small test cases.  If it is too much, we can remove this
Create procedure.  The test program I attached has an example.


>
> >   --  Shows or hidees a dialog
>
> Little typo.
>

Thanks!


>
> >procedure Remove (Dialog : in out Dialog_Type);
> >--  Removes an element from the DOM, if the ID_Type is DOM_ID, the ID
>
> Removes the dialog?
>

Yes, this maybe overkill.  It cannot be dynamically managed in version 2
but you can still remove it from the DOM (if I did it correctly) in cases
where you want to manually manage stuff.  Kind of a compromise.  any of
this stuff is up for debate/removal.


gnoga-gui-modal_dialog.adb
Description: Binary data


gnoga-gui-modal_dialog.ads
Description: Binary data


gnoga-gui-view-modal_dialog.adb
Description: Binary data


gnoga-gui-view-modal_dialog.ads
Description: Binary data


test_dialog.adb
Description: Binary data


test_dialog.ads
Description: Binary data
--
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

Re: [Gnoga-list] Modal dialog box

[Jeremiah Breeden]

Thinking more on it, I probably under represented the cons for #2.
They are all related but just to be complete:
1.  Cannot be used in a lot Gnoga API calls due to not extending any Gnoga
types
2.  Doesn't follow the standard Gnoga creation patterns (the Con I
mentioned ealier)
3.  Unable to set it as Dynamic and have another Gnoga component manage
deleting
pointers to it.  So you have to manually manage memory with it (or use a
smart access
container type).

There may be others that I am not considering.

That said, I still prefer #2 over #1.  I am mostly presenting #1 because it
looks and acts
more like a Gnoga type and I know some people might prefer that.

On Fri, Jun 2, 2017 at 11:51 AM, Jeffrey R. Carter  wrote:

> On 06/02/2017 02:44 AM, Jeremiah Breeden wrote:
> > So an update.  I have two different implementations.  They each have
> pros and
> > cons and wanted to get feedback on which one would be better to submit.
> I can
> > submit both if desired
>
> I prefer Version 2. Version 1 has too many cons; Version 2 only has 1.
>
> --
> Jeff Carter
> "When and now is this guitar piece from Stottlemeyer?
> Yes, it's with Mr. Dog in Gertrude's pinball forest."
> The World's Funniest Joke
> 133
>
>
> 
> --
> 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
>
--
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

Re: [Gnoga-list] Modal dialog box

[Jeremiah Breeden]

);
   --  Attach and create a user created view to the dialog.  Call this
   --  in place of the Create procedure for the view supplied.

   procedure Show
  (Dialog : in out Dialog_Type;
   Show   :Boolean := True;
   Center :Boolean := True);
   --  Shows or hidees a dialog

   procedure Center (Dialog : in out Dialog_Type);
   --  Center a dialog within its parent window or view

   procedure Top (Dialog : in out Dialog_Type; Top  : Integer);
   --  Set the "top" position of the dialog.

   procedure Left (Dialog : in out Dialog_Type; Left : Integer);
   --  Set the "left" position of the dialog.

   procedure Modal_Background_Color
  (Dialog : in out Dialog_Type;
   Color  :String);
   --  Change the background color of the modal dialog's fill view

   procedure Modal_Background_Color
  (Dialog : in out Dialog_Type;
   Color  :Gnoga.Types.Colors.Color_Enumeration);
   --  Change the background color of the modal dialog's fill view

   procedure Remove (Dialog : in out Dialog_Type);
   --  Removes an element from the DOM, if the ID_Type is DOM_ID, the ID
   --  will be changed to a unique Gnoga_ID before removal.

private

   type Dialog_Type is tagged limited record
  Modal_Background : Gnoga.Gui.View.View_Type;
  Modal_Frame  : Gnoga.Gui.View.View_Type;
   end record;

end Gnoga.Gui.Modal_Dialog;

*

On Thu, May 25, 2017 at 2:52 PM, Pascal wrote:

> Hello Jeremiah,
>
> What about of deriving Modal_Dialog from View_Base_Type in a package named
> Gnoga.Gui.View.Modal_Dialog.Dialog_Type?
>
>type Dialog_Type is new Gnoga.Gui.View.View_Base_Type with record
>   Main_View : Gnoga.Gui.View.View_Access := null;
>end record;
>
> It may solve the issue of Gauthier?
>
> > modal.adb:69:16: ambiguous call to "Create"
> > modal.adb:69:16: possible interpretation (inherited) at line 17
> > modal.adb:69:16: possible interpretation (inherited) at line 17
>
>
> Well, the simplest is to put it in Gnoga dev_1.3 branch and lets use it ;-)
>
> Could you please send source codes in files with standard Gnoga header and
> so on?
> See https://sourceforge.net/p/gnoga/wiki/Coding-Guidelines.
>
> Thanks, Pascal.
> http://blady.pagesperso-orange.fr
>
>
> > Le 17 mai 2017 à 05:19, Jeremiah Breeden a écrit :
> >
> > So after trying a bunch of implementations, I am leaning towards the
> following:
> >
> >
>
> <...>
>
> > Thoughts?
> >
>
>
--
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

Re: [Gnoga-list] Fwd: Modal dialog box

[Jeremiah Breeden]

So even though I specifically use View_Base_Type in the public extension,
the private extension of View_Type is actually public as well?  I was
hoping that client packages couldn't see into a private section of a
package (well unless they are child packages).  That's kinda stinky.

On Fri, May 26, 2017 at 10:32 AM, Jeffrey R. Carter 
wrote:

> On 05/25/2017 11:51 PM, Jeremiah Breeden wrote:
>
>type Dialog_Type is new Gnoga.Gui.View.View_Base_Type with private;
>
> private
>
>type Dialog_Type is new Gnoga.Gui.View.View_Type with record
>   Main_View : Gnoga.Gui.View.View_Access := null;
>end record;
>
>
> Your derivation is public. What fields you added is private. You probably
> want
>
>type Dialog_Type is tagged private;
>
> private
>
> type Dialog_Type is new Gnoga.Gui.View.View_Type with record  
> Main_View : Gnoga.Gui.View.View_Access := null;
>end record;
>
>
> --
> Jeff Carter
> "Nobody expects the Spanish Inquisition!"
> Monty Python's Flying Circus
> 22
>
>
>
--
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

[Gnoga-list] Fwd: Modal dialog box

[Jeremiah Breeden]

I do want the Create method of View_Type privately, so what I tried to do
was

   type Dialog_Type is new Gnoga.Gui.View.View_Base_Type with private;

private

   type Dialog_Type is new Gnoga.Gui.View.View_Type with record
  Main_View : Gnoga.Gui.View.View_Access := null;
   end record;

I was hoping by making the actual inheritance private that it would prevent
the issue, but I was still getting ambiguous calls to Create.  I am hoping
someone at CLA can see if that is a bug or not.

That said, I think I have a better implementation.  I just need to iron
some things out on it before it is ready.

On Thu, May 25, 2017 at 2:52 PM, Pascal  wrote:

> Hello Jeremiah,
>
> What about of deriving Modal_Dialog from View_Base_Type in a package named
> Gnoga.Gui.View.Modal_Dialog.Dialog_Type?
>
>type Dialog_Type is new Gnoga.Gui.View.View_Base_Type with record
>   Main_View : Gnoga.Gui.View.View_Access := null;
>end record;
>
> It may solve the issue of Gauthier?
>
> > modal.adb:69:16: ambiguous call to "Create"
> > modal.adb:69:16: possible interpretation (inherited) at line 17
> > modal.adb:69:16: possible interpretation (inherited) at line 17
>
>
> Well, the simplest is to put it in Gnoga dev_1.3 branch and lets use it ;-)
>
> Could you please send source codes in files with standard Gnoga header and
> so on?
> See https://sourceforge.net/p/gnoga/wiki/Coding-Guidelines.
>
> Thanks, Pascal.
> http://blady.pagesperso-orange.fr
>
>
> > Le 17 mai 2017 à 05:19, Jeremiah Breeden  a
> écrit :
> >
> > So after trying a bunch of implementations, I am leaning towards the
> following:
> >
> >
>
> <...>
>
> > Thoughts?
> >
>
>
--
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

[Gnoga-list] Disappearing Width/Height

[Jeremiah Breeden]

I'm running into something that I wanted to understand the "why" on.  I
already have a workaround, but I want to see what is causing the issue.
I've been playing around with a custom dialog type made from Gnoga
elements.  What I am finding is if the supplied user view to my Dialog_Type
functions has Fill_Parent set, then one of my internal views loses its
width/height info.  I whittled it down to a smaller example.  For
reference, the Fill_View is the view that will block other content while
the Frame_View is the containing view to whatever other view is supplied.
To compile and run this file, just pick any multiconnect example and attach
Test_Width.On_Connect to it.  If I comment out the line:

App.User_View.Fill_Parent;

Then everything works correct.  I am wondering how calling Fill_Parent on
User_View changes the Width and Height on Frame_View

Test_Width.ads
**
with Gnoga.Types;
with Gnoga.Gui.Window;
with Gnoga.Gui.View;
with Gnoga.Application.Multi_Connect;

package Test_Width is

   procedure On_Connect
  (Main_Window : in out Gnoga.Gui.Window.Window_Type'Class;
   Connection  : access
  Gnoga.Application.Multi_Connect.Connection_Holder_Type);

end Test_Width;



Test_Width.adb
**
with ada.Text_IO;
with Gnoga.Gui.Element;
with Gnoga.Gui.View.Grid;
with Gnoga.Gui.Element.Common;

package body Test_Width is

   type App_Data
  (Window : not null access Gnoga.Gui.Window.Window_Type'Class)
   is new Gnoga.Types.Connection_Data_Type with record
  Main_View : Gnoga.Gui.View.View_Type;
  Fill_View : Gnoga.Gui.View.View_Type;
  Frame_View : Gnoga.Gui.View.View_Type;
  User_View : Gnoga.Gui.View.View_Type;
  Grid  : Gnoga.Gui.View.Grid.Grid_View_Type;
  Button : Gnoga.Gui.Element.Common.Button_Type;
   end record;

   type App_Access is access all App_Data;

   -- Centers Child_View inside of Parent_View
   procedure Center
  (Parent_View : in out Gnoga.Gui.View.View_Type;
   Child_View  : in out Gnoga.Gui.View.View_Type)
   is
  Top_Offset : Integer
 := (Parent_View.Height/2
 - Child_View.Height/2);
  Left_Offset : Integer
 := (Parent_View.Width/2
 - Child_View.Width/2);

  use type String;
   begin

  -- Bound to top left corner
  if Top_Offset < 0 then
 Top_Offset := 0;
  end if;
  if Left_Offset < 0 then
 Left_Offset := 0;
  end if;
  Child_View.Top
 (Parent_View.Offset_From_Top  + Top_Offset);
  Child_View.Left
 (Parent_View.Offset_From_Left + Left_Offset);

   end Center;

   -- Shows Parent_Viewe, Child_View, and other children
   -- Centers it if desired
   procedure Show
  (Parent_View : in out Gnoga.Gui.View.View_Type;
   Child_View  : in out Gnoga.Gui.View.View_Type;
   Show   :Boolean := True;
   Center :Boolean := True)
   is
   begin
  if Show then
 Parent_View.Hidden(False);
 if Center then
Test_Width.Center(Parent_View,Child_View);
 end if;
 Parent_View.Visible;
  else
 Parent_View.Visible(False);
 Parent_View.Hidden;
  end if;

   end Show;

   procedure Init(App : in out App_Data) is
  use Gnoga.Gui.View.Grid;
   begin
  App.Main_View.Create(App.Window.all);

  -- Configure the Filling View (Grey background)
  App.Fill_View.Create(App.Main_View);
  App.Fill_View.Place_Inside_Top_Of(App.Main_View);
  App.Fill_View.Fill_Parent;
  App.Fill_View.Background_Color("Grey");

  -- Configure the Frame View (holds the user view
  -- and provides centering capability).
  App.Frame_View.Create(App.Fill_View);
  App.Frame_View.Position(Gnoga.Gui.Element.Fixed);
  App.Frame_View.Background_Color("White");

  -- Hide everything for now
  Show
 (Parent_View => App.Fill_View,
  Child_View  => App.Frame_View,
  Show=> False,
  Center  => False);

  -- Configure the user view
  App.User_View.Create(App.Frame_View);

  -- This line causes Frame_View to lose width/height info
  App.User_View.Fill_Parent;

  App.Button.Create(App.User_View,"Test");
  App.User_View.Height(200);
  App.User_View.Width(300);

  -- Show the Fill_View and its children
  Show
 (Parent_View => App.Fill_View,
  Child_View  => App.Frame_View,
  Show=> True,
  Center  => True);

   end Init;

   procedure Print(App : App_Data) is
   begin
  Ada.Text_IO.Put_Line
 ("Main_View:  "
  & Integer'Image(App.Main_View.Height)
  & ","
  & Integer'Image(App.Main_View.Width));
  Ada.Text_IO.Put_Line
 ("Fill_View:  "
  & Integer'Image(App.Fill_View.Height)
  & ","
  & Integer'Image(Ap

Re: [Gnoga-list] Modal dialog box

[Jeremiah Breeden]

.Gui.Modal_Dialog.Dialog_Type;
 Modal_View : Gnoga.Gui.View.View_Type;
 Show_Dlg_Bttn  : Gnoga.Gui.Element.Common.Button_Type;
 Hide_Dlg_Bttn  : Gnoga.Gui.Element.Common.Button_Type;
 -- Add other controls here
  end record;
   type App_Access is access all App_Data;


  -- Create Dialog Frame
  App.Modal.Create(App.Main_Window.all);

  -- Attach a view to the dialog frame
  App.Modal_View.Create(App.Modal.Get_View.all);
  App.Modal_View.Width(400);
  App.Modal_View.Height(300);

  App.Modal_View.Put_Line("Modal Dialog");
  App.Hide_Dlg_Bttn.Create(App.Modal_View,"Hide Dialog");
  App.Hide_Dlg_Bttn.On_Click_Handler(On_Hide_Dlg_Click'Access);

*******

Thoughts?

On Tue, May 16, 2017 at 8:34 PM, Jeremiah Breeden wrote:

> I'll mess around with it more.  What I posted earlier was just stuff I did
> for local small projects, so I never spent the needed time to make them a
> more general better solution.
>
> On Tue, May 16, 2017 at 12:43 PM, Gautier de Montmollin wrote:
>
>> There is a small banana skin with the Create method: when I try to
>> extend Gnoga.Gui.View.Modal_Dialog.Dialog_Type for containing its own
>> buttons and other elements, like this:
>> 
>>
>
--
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

Re: [Gnoga-list] Modal dialog box

[Jeremiah Breeden]

Yeah, Ada doesn't have a good method of preventing overriding of methods.
I made the one version private, but forgot that derived types can still
override them.  I wish Ada had a way to mark procedures as final.

Out of the two options you mentioned, I think #2 is probably better, but
you want to make sure you do a test to see if the input type is of
Window_Type'Class before doing those casts.  You might also consider
casting them to Window_Type'Class rather than just Window_Type in case a
derived type is passed in.

Still I wish I could come up with a better compile time safe method.  I
could make Dialog_Type completely private so View_Type isn't a public
ancestor, but I would need a better method of attaching the views to it,
and it most likely wouldn't follow the Gnoga style.  The other way is for
me to back off the composition and simply make the Modal_Background the
actual Dialog_Type.  Doing that would mean that I need to move some of the
create code into Show and push off the location/size of the view completely
to the implementing client (or also into Show, but with record members that
can save the most recent values of them).  Alternately, I could also take a
look at tabs and cards in Gnoga and see if there are any constructs there
to borrow.

I'll mess around with it more.  What I posted earlier was just stuff I did
for local small projects, so I never spent the needed time to make them a
more general better solution.

On Tue, May 16, 2017 at 12:43 PM, Gautier de Montmollin  wrote:

> There is a small banana skin with the Create method: when I try to
> extend Gnoga.Gui.View.Modal_Dialog.Dialog_Type for containing its own
> buttons and other elements, like this:
>
> type Custom_Modal_Type is new
> Gnoga.Gui.View.Modal_Dialog.Dialog_Type with record
>Hide_Dlg_Bttn  : Gnoga.Gui.Element.Common.Button_Type;
> end record;
>
> changing the App_Data like this:
>
> type App_Data (Main_Window : access
> Gnoga.Gui.Window.Window_Type'Class) is
>new Gnoga.Types.Connection_Data_Type
> with
>record
>   Top_Level_View : Gnoga.Gui.View.View_Type;
>   Modal  : Custom_Modal_Type;
>   Show_Dlg_Bttn  : Gnoga.Gui.Element.Common.Button_Type;
>   --  Add other controls here
>end record;
>
> (and the code around the inner button as following:
>App.Modal.Hide_Dlg_Bttn.Create (App.Modal, "Hide Dialog");
>App.Modal.Hide_Dlg_Bttn.On_Click_Handler
> (On_Hide_Dlg_Click'Unrestricted_Access);
> )
>
> then the Create method becomes ambiguous to GNAT (GPL 2016):
>
>App.Modal.Create (App.Main_Window.all);
>
> modal.adb:69:16: ambiguous call to "Create"
> modal.adb:69:16: possible interpretation (inherited) at line 17
> modal.adb:69:16: possible interpretation (inherited) at line 17
>
> My guess is that it hesitates between the Create in
> Gnoga.Gui.View.Modal_Dialog and the one in Gnoga.Gui.View.
>
> My fix #1 is to rename Create as Create_Modal.
> But I guess you want to prevent people using the Gnoga.Gui.View.Create
> for the modal dialogs.
>
> So my fix #2 is to define this public,
>
> overriding
> procedure Create
>(View : in out Dialog_Type;
> Parent   : in out Gnoga.Gui.Base.Base_Type'Class;
> ID   : in String := "");
>
> then in the body, convert to Window_Type when needed:
> 11:  Old_View : Gnoga.Gui.Base.Pointer_To_Base_Class :=
> Gnoga.Gui.Window.Window_Type(Parent).Get_View;
> 18: Gnoga.Gui.Window.Window_Type(Parent).Set_View(Old_View.all);
>
> Comments ? Better ideas ?
> Cheers
> Gautier
>
>
>
> 
> --
> 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
>
--
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

Re: [Gnoga-list] On_Destroy handler.

[Jeremiah Breeden]

Just did a few different tests.  Since Element_Type is derived from tagged
type Base_Type, the On_Destroy procedure is inherited and there is an
implicit On_Destory(Object : in out Element_Type) created in
Gnoga.Gui.Elements.  When you provide a "use" clause in your main
subprogram, it brings that inherited version into scope.   Then you create
your On_Destroy(Object : in out Base_Type'Class) procedure.  At this point
you have two On_Destroy procedures in scope.  When you try to assign it to
the On_Destroy_Handler procedure, it can't tell which of the two versions
of On_Destroy you want to take the 'Access of.

I think the error messages could be clearer, but I think that is correct
operation as far as the compiler is concerned.  I don't know if it can
resolve the 'Access based on the expected prototype.  General user thought
process might expect that the compiler can pick the one that matches the
Action_Event prototype, but I am not a compiler writer, so I am not sure
how easy it is to do that nor do I know what the standard dictates for this.

On Sun, May 14, 2017 at 10:04 AM, Jeremiah Breeden <
jeremiah.bree...@gmail.com> wrote:

> The error seems off to me.  What I found was it was your "use
> Gnoga.Gui.Element" line.  In seems to expose the On_Destroy from
> Gnoga.Gui.Base into scope so that your On_Destroy method and the one in
> Gnoga.Gui.Base conflict somehow.
>
> Taking out the use and adding to Gnoga.Gui.Element. to the various calls
> is an alternate way of fixing it.
>
> I'm not sure why the two procedures conflict.  They have different
> signatures, and the conflicting procedure isn't even in the package that is
> "use"ed
>
> This might be a question for comp.lang.ada.  If I get time later, I'll try
> and parse through the RM to see if this is a bug or not, but it does seem
> odd.  Maybe inherited functions of tagged types get exposed to the package
> that extends those types.  If so, that is why On_Destroy would conflict in
> your call.  Going only by the name of the procedure with not context, it
> happens to chose the one from Gnoga.Gui.Base, which doesn't match the
> Action_Event prototype.
>
> On Sun, May 14, 2017 at 4:33 AM, Pascal  wrote:
>
>> Hello,
>>
>> I've added a destroy handler to multiuser.adb test program:
>>
>>
>>
>> But I've got the following error with GNAT GPL 2016:
>>
>> gprbuild -ws -c -f -u -P/gnoga-code/test/test.gpr
>> -XLIB_COMPONENTS_BUILD=default -XPRJ_TARGET=OSX -XPRJ_BUILD=Debug
>> multiuser.adb
>> gcc -c -gnaty3abcefhiklM120nOprsStu -gnat2012 -gnatW8 -g -gnata -gnatq
>> -gnatQ -gnatw.eH.YD -gnatVa -gnato -fstack-check -gnatf -gnateE -gnateF
>> -gnatec=/gnoga-code/pragma_debug.adc -fno-common multiuser.adb
>> multiuser.adb:64:07: warning: "App" is not modified, could be declared
>> constant
>> multiuser.adb:81:07: warning: "App" is not modified, could be declared
>> constant
>> multiuser.adb:94:07: warning: "App" is not modified, could be declared
>> constant
>> multiuser.adb:103:07: warning: "App" is not modified, could be declared
>> constant
>> multiuser.adb:109:07: warning: variable "App" is not referenced
>> multiuser.adb:119:07: warning: "App" is not modified, could be declared
>> constant
>> multiuser.adb:193:43: no candidate interpretations match the actuals:
>> multiuser.adb:193:43: missing argument for parameter "Object" in call to
>> "On_Destroy" declared at line 115
>> multiuser.adb:193:43: missing argument for parameter "Object" in call to
>> "On_Destroy" (inherited) at gnoga-gui-element.ads:51
>> multiuser.adb:193:43: context requires function call, found procedure name
>> multiuser.adb:193:53:   ==> in call to inherited operation
>> "On_Destroy_Handler" at gnoga-gui-window.ads:56
>> multiuser.adb:218:07: warning: "D" modified by call, but value never
>> referenced
>> gprbuild: *** compilation phase failed
>> [2017-05-14 10:21:43] process exited with status 4, elapsed time: 00.69s
>>
>> If I change ligne 193 to:
>>
>>  App.Main_Window.On_Destroy_Handler (Multiuser.On_Destroy'Unrestri
>> cted_Access);
>>
>> No more errors.
>>
>> Why these errors not so much clear are issued?
>> Why local procedure On_Destroy isn't visible?
>>
>> Thanks, Pascal.
>> http://blady.pagesperso-orange.fr
>>
>>
>>
>> 
>> --
>> 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
>>
>>
>
--
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

Re: [Gnoga-list] On_Destroy handler.

[Jeremiah Breeden]

The error seems off to me.  What I found was it was your "use
Gnoga.Gui.Element" line.  In seems to expose the On_Destroy from
Gnoga.Gui.Base into scope so that your On_Destroy method and the one in
Gnoga.Gui.Base conflict somehow.

Taking out the use and adding to Gnoga.Gui.Element. to the various calls is
an alternate way of fixing it.

I'm not sure why the two procedures conflict.  They have different
signatures, and the conflicting procedure isn't even in the package that is
"use"ed

This might be a question for comp.lang.ada.  If I get time later, I'll try
and parse through the RM to see if this is a bug or not, but it does seem
odd.  Maybe inherited functions of tagged types get exposed to the package
that extends those types.  If so, that is why On_Destroy would conflict in
your call.  Going only by the name of the procedure with not context, it
happens to chose the one from Gnoga.Gui.Base, which doesn't match the
Action_Event prototype.

On Sun, May 14, 2017 at 4:33 AM, Pascal  wrote:

> Hello,
>
> I've added a destroy handler to multiuser.adb test program:
>
>
>
> But I've got the following error with GNAT GPL 2016:
>
> gprbuild -ws -c -f -u -P/gnoga-code/test/test.gpr
> -XLIB_COMPONENTS_BUILD=default -XPRJ_TARGET=OSX -XPRJ_BUILD=Debug
> multiuser.adb
> gcc -c -gnaty3abcefhiklM120nOprsStu -gnat2012 -gnatW8 -g -gnata -gnatq
> -gnatQ -gnatw.eH.YD -gnatVa -gnato -fstack-check -gnatf -gnateE -gnateF
> -gnatec=/gnoga-code/pragma_debug.adc -fno-common multiuser.adb
> multiuser.adb:64:07: warning: "App" is not modified, could be declared
> constant
> multiuser.adb:81:07: warning: "App" is not modified, could be declared
> constant
> multiuser.adb:94:07: warning: "App" is not modified, could be declared
> constant
> multiuser.adb:103:07: warning: "App" is not modified, could be declared
> constant
> multiuser.adb:109:07: warning: variable "App" is not referenced
> multiuser.adb:119:07: warning: "App" is not modified, could be declared
> constant
> multiuser.adb:193:43: no candidate interpretations match the actuals:
> multiuser.adb:193:43: missing argument for parameter "Object" in call to
> "On_Destroy" declared at line 115
> multiuser.adb:193:43: missing argument for parameter "Object" in call to
> "On_Destroy" (inherited) at gnoga-gui-element.ads:51
> multiuser.adb:193:43: context requires function call, found procedure name
> multiuser.adb:193:53:   ==> in call to inherited operation
> "On_Destroy_Handler" at gnoga-gui-window.ads:56
> multiuser.adb:218:07: warning: "D" modified by call, but value never
> referenced
> gprbuild: *** compilation phase failed
> [2017-05-14 10:21:43] process exited with status 4, elapsed time: 00.69s
>
> If I change ligne 193 to:
>
>  App.Main_Window.On_Destroy_Handler (Multiuser.On_Destroy'
> Unrestricted_Access);
>
> No more errors.
>
> Why these errors not so much clear are issued?
> Why local procedure On_Destroy isn't visible?
>
> Thanks, Pascal.
> http://blady.pagesperso-orange.fr
>
>
>
> 
> --
> 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
>
>
--
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

Re: [Gnoga-list] Modal dialog box

[Jeremiah Breeden]

I kinda hacked one in using standard Gnoga items.  I don't know how good it
is from a production
perspective, but it works out ok for my at home stuff.  There's still lots
of work to make it fully Gnoga
ready, but here is a basic Modal Dialog.

It can definitely be expanded upon and I haven't gotten into what it needs
to add Remove/Attach type functions correctly, so it currently doesn't
support that kind of stuff.  It's basically designed to be added to a
window and not removed until the window is destroyed.  Other functions will
need to be added if
you want to modify the modal background other than color, but this leaves a
blueprint on how to do it.

gnoga-gui-view-modal_dialog.ads

with Gnoga.Gui.Window;
with Gnoga.Gui.Base;
with Gnoga.Types.Colors;

package Gnoga.Gui.View.Modal_Dialog is

   type Dialog_Type is new View_Type with private;
   type Dialog_Access is access all Dialog_Type;
   type Pointer_To_Dialog_Class is access all Dialog_Type'Class;

   procedure Create
  (View : in out Dialog_Type;
   Parent   : in out Gnoga.Gui.Window.Window_Type'Class;
   ID   : in String := "");

   procedure Show
  (View : in out Dialog_Type;
   Show :Boolean := True);

   procedure Center(View : in out Dialog_Type);

   procedure Modal_Background_Color
  (View  : in out Dialog_Type;
   Color :String);

   procedure Modal_Background_Color
  (View  : in out Dialog_Type;
   Color :Gnoga.Types.Colors.Color_Enumeration);

private

   overriding
   procedure Create
  (View   : in out Dialog_Type;
   Parent : in out Gnoga.Gui.Base.Base_Type'Class;
   ID : in String := "") is null;

   type Dialog_Type is new View_Type with record
  Modal_Background : View_Type;
   end record;

end Gnoga.Gui.View.Modal_Dialog;


gnoga-gui-view-modal_dialog.adb

with Gnoga.Gui.Element;

package body Gnoga.Gui.View.Modal_Dialog is

   procedure Create
  (View   : in out Dialog_Type;
   Parent : in out Gnoga.Gui.Window.Window_Type'Class;
   ID : in String := "")
   is
  -- Copy of Parent's Main View
  Old_View : Gnoga.Gui.Base.Pointer_To_Base_Class := Parent.Get_View;
   begin
  -- Create view
  View.Modal_Background.Create(Parent);

  -- Creating a view using a window as a parent sets the view as the
  -- window's main view.  This line sets it back to the original.
  Parent.Set_View(Old_View.all);

  -- Configure the Modal Background
  View.Modal_Background.Fill_Parent;
  View.Modal_Background.Background_Color(Value => "Grey");

  -- Set the default show/hide state
  View.Show(False);

  -- Create the Dialog
  View_Type(View).Create
 (Parent => View.Modal_Background,
  ID => ID);

  -- Configure the dialog
  View.Background_Color(Value => "White");
  View.Width(Value => 400);
  View.Height(Value => 300);
  View.Position(Value => Gnoga.Gui.Element.Fixed);
  View.Center;

   end Create;

   procedure Show
  (View : in out Dialog_Type;
   Show :Boolean := True)
   is
   begin
  if Show then
 View.Modal_Background.Z_Index(Integer'Last);
 View.Modal_Background.Opacity(1.0);
 View.Modal_Background.Hidden(False);
  else
 View.Modal_Background.Hidden;
 View.Modal_Background.Opacity(0.0);
 View.Modal_Background.Z_Index(Integer'First);
  end if;

   end Show;

   procedure Center(View : in out Dialog_Type) is
  Frame : View_Type renames View.Modal_Background;
   begin
  View.Top (Value => Frame.Position_Top  + Frame.Height/2 -
View.Height/2);
  View.Left(Value => Frame.Position_Left + Frame.Width/2  -
View.Width/2);
   end Center;

   procedure Modal_Background_Color
  (View  : in out Dialog_Type;
   Color :String)
   is
   begin
  View.Modal_Background.Background_Color(Color);
   end Modal_Background_Color;

   procedure Modal_Background_Color
  (View  : in out Dialog_Type;
   Color :Gnoga.Types.Colors.Color_Enumeration)
   is
   begin
  View.Modal_Background.Background_Color(Color);
   end Modal_Background_Color;

end Gnoga.Gui.View.Modal_Dialog;


Example Setup Code:

   type App_Data(Main_Window : access Gnoga.Gui.Window.Window_Type'Class) is
  new Gnoga.Types.Connection_Data_Type
   with
  record
 Top_Level_View : Gnoga.Gui.View.View_Type;
 Modal  : Gnoga.Gui.View.Modal_Dialog.Dialog_Type;
 Show_Dlg_Bttn  : Gnoga.Gui.Element.Common.Button_Type;
 Hide_Dlg_Bttn  : Gnoga.Gui.Element.Common.Button_Type;
 -- Add other controls here
  end record;
   type App_Access is access all App_Data;

   p

Re: [Gnoga-list] Task Safety and Connection_Data

[Jeremiah Breeden]

On Sun, Apr 9, 2017 at 3:46 PM, Jeffrey R. Carter wrote:

> On 04/09/2017 09:00 PM, Jeremiah Breeden wrote:
> >
> > I took a look.  It looks like your entry is actually "per connection"
> unless I
> > misunderstand.  Your app data structure has the serializer as part of the
> > record.  Doesn't that mean that each connection gets their own
> serializer?
>
> You're right. I guess my memory of what I'd done was wrong. Sorry to
> mislead you.
>

Oh, not at all!  Not misleading.  I just wanted to make sure I wasn't
missing something there.  Ada is not my first language, so I could have
easily been making a noob mistake.  Thank you again!
--
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

Re: [Gnoga-list] Task Safety and Connection_Data

[Jeremiah Breeden]

On Sat, Apr 8, 2017 at 4:40 AM, Jeffrey R. Carter wrote:

> On 04/08/2017 03:05 AM, Jeremiah Breeden wrote:
> > I was trying to figure out how Connection_Data  is handled with respect
> to Task
> > safety.  In particular, if I have two Action_Event handlers and in each
> of the I
> > do something like:
> >
> > My_App : My_App_Access := My_App_Access(Object.Connection_Data);
> >
> > And then proceed to use it in both action event handlers, how does Gnoga
> prevent
> > the two handlers from having concurrency issues with what My_App points
> to?
>
> This is only an issue if the events are both from the same connection. If
> the
> events are from different connections, then the pointers are different and
> you
> don't have to worry about it. Multi-connect programs would be difficult to
> implement if this wasn't the case.
>
> Since events are really user interactions with the Gnoga GUI, and
> computers are
> much faster than people, this is not a concern for most programs.
>
> However, Gnoga seems to respond to a user interaction by creating a task
> which
> calls the appropriate event handler. If the processing of one event can
> take
> long enough that the user can generate another event, then this can become
> an
> issue. I encountered this when porting Mine_Detector to Gnoga. The
> responses to
> some events at some points in the game took seconds, and it was easy to
> generate
> a 2nd event which would interfere with the 1st and result in an invalid
> game
> state. My solution was for all event handlers to call a protected entry,
> serializing the event handling. I used an entry with a barrier of True
> rather
> than a protected procedure so the calls would be queued and handled in the
> correct order.
>

This is kind of the same type of case for me.  I have some events that may
take a longer time, so the events could overlapp.  I wanted to check
because Gnoga is advertised as being built with concurrency in mind, but I
had noticed that the basic mechanism for getting a connection's data
structure might be dangerous in that respect.  I wanted to make sure I
wasn't missing something.  (note that I am not saying the advert is wrong,
just my interpretation of it).  In either case, it wasn't something that
was intuitive to me at first glance.  Since each event happens in its own
task, I had hoped that the connection data object that the event object has
access to would have been task safe.  Now that I know, I can make sure to
be careful when I have use cases that matter.  Thanks for clearing it up
for me!


> On Sat, Apr 8, 2017 at 4:40 AM, Jeffrey R. Carter wrote:
> My solution is really for the singleton case, though. In the multi-connect
> version, all the event handlers are going through the same entry, so an
> event
> has to wait for all other players' events to complete before being
> processed.
> The multi-connect version should really have a protected object per
> connection.
>
> You can see the Mine_Detector code in Gnoga's demo directory.
>

I took a look.  It looks like your entry is actually "per connection"
unless I misunderstand.  Your app data structure has the serializer as part
of the record.  Doesn't that mean that each connection gets their own
serializer?
--
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

[Gnoga-list] Task Safety and Connection_Data

[Jeremiah Breeden]

I was trying to figure out how Connection_Data  is handled with respect to
Task safety.  In particular, if I have two Action_Event handlers and in
each of the I do something like:

My_App : My_App_Access := My_App_Access(Object.Connection_Data);

And then proceed to use it in both action event handlers, how does Gnoga
prevent the two handlers from having concurrency issues with what My_App
points to?

As far as I can tell, Connection_Data is stored simply as an access
variable in the connection_manager.  Granted, the function to get the
access variable is from a protected object, but we copy that pointer into a
local unprotected access variable.  What prevents both handlers from trying
to set the same parameter at the same time (not talking about the
parameters pushed via the websocket but those stored locally in the
object...maps, Strings, counts, etc.)?
--
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

Re: [Gnoga-list] My two cents/patches contribution

[Jeremiah Breeden]

Would 0001 inhibit building using MinGW?

On Fri, Jun 3, 2016 at 7:16 AM, Jean-Pierre Rosen  wrote:

> 0002-Put-Id-of-missing-object-in-exception-message-when-G.patch
> To get a bit more information in case of dispatching to non-existent object
>
> 0001-Force-PREFIX-to-Windows-syntax-when-used-with-cygwin.patch
> Under windows (with cygwin), make install didn't work because of the
> /cygdrive/c syntax that isn't understood by gprinstall. This patch turns
> cygwin syntax into windows syntax.
>
> --
> J-P. Rosen
> Adalog
> 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
> Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
> http://www.adalog.fr
>
>
> --
> What NetFlow Analyzer can do for you? Monitors network bandwidth and
> traffic
> patterns at an interface-level. Reveals which users, apps, and protocols
> are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
> ___
> Gnoga-list mailing list
> Gnoga-list@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gnoga-list
>
>
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e___
Gnoga-list mailing list
Gnoga-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gnoga-list

Re: [Gnoga-list] Dropping the ball

[Jeremiah Breeden]

No worries at all David.  I am sorry for your family's loss.  Our hearts
and prayers go out to you and your family.

Regards and condolences,
Jeremiah

On Sat, May 28, 2016 at 11:57 PM, Rabbi David Botton 
wrote:

> I'm fairly embarrassed to have been off the grid for so long with Gnoga
> and thankful to Pascal and others still working hard on things. Has been a
> tough time business wise last months and most recently with my father's
> passing and trying to get things in order. I wish Gnoga had a higher
> priority than food and family but I've not given up on things and
> hopefully more involved soon :) I still have a number of plans for Gnoga's
> development and tools for it.
>
> David Botton
>
>
>
> --
> What NetFlow Analyzer can do for you? Monitors network bandwidth and
> traffic
> patterns at an interface-level. Reveals which users, apps, and protocols
> are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
> ___
> Gnoga-list mailing list
> Gnoga-list@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gnoga-list
>
>
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e___
Gnoga-list mailing list
Gnoga-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gnoga-list

Re: [Gnoga-list] Question about endless connection swapping

[Jeremiah Breeden]

User_Data.Window.Close is just for child windows that are launched
according to the comments in the Gnoga code base.  Close_Connection does
close the connection, but it doesn't push the HTML_On_Close and you do
still get some of the swapping still (though only like 2 swaps now...not
endless).  I haven't found a very clean or reliable way to close a
connection via user input in multi-connect yet.  Maybe someone else knows a
good way?

On Tue, Mar 15, 2016 at 8:10 AM, Olivier Henley 
wrote:

> On Mon, Mar 14, 2016 at 8:14 PM, Rabbi David Botton 
> wrote:
>
>> Did you close and restart a gnoga server in a small space of time?
>>
>
> No but I am implementing automatic session closing when a client opens a
> new session on another computer or another tab.
>
> It looks like the 'closed sessions' still have their client side websocket
> trying to communicate... is that it?
>
> I call this to force close a session:
>
> User_Data.Window.Close;
> User_Data.Window.Close_Connection;
>
> Is it not enough?
>
> Thanks.
>
>
>
>
> --
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
> ___
> Gnoga-list mailing list
> Gnoga-list@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gnoga-list
>
>
--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
Gnoga-list mailing list
Gnoga-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gnoga-list

Re: [Gnoga-list] Zany Blue and Gnoga_Tools requirement?

[Jeremiah Breeden]

Thank you for taking a look at that!  I know I can get annoying with all
these Windows issues, but I really do want to see more Windows developers
take a better look at Ada.


On Thu, Apr 14, 2016 at 2:41 PM, Pascal 
wrote:

> Hello Jeremiah,
>
> Well the underlying issue for both cases is that some source files are
> generate with Windows processes and then with CR LF terminators that are
> don't wanted by Gnoga style option -gnatyd.
> "Check no DOS line terminators present.
> All lines must be terminated by a single ASCII.LF character (in particular
> the DOS line terminator sequence CR/LF is not allowed)."
> With gnatprep for zanyblue.adb and with zbmcompile for connectfour files.
> gnatprep has -T option that is "Use LF as line terminators when writing
> files. By default the line terminator of the host (LF under unix, CR/LF
> under Windows) is used."-> good point.
> Concerning zbmcompile, I will send the issue to its author.
>
> In the meanwhile, you can safely remove this compilation flag:
> settings.gpr patch:
> -   Common_Options := ("-gnaty3abcdefhiklmnOprsStu","-gnat2012",
> "-gnatW8");
> +   Common_Options := ("-gnaty3abcefhiklmnOprsStu","-gnat2012", "-gnatW8");
> and as you did :
> deps/zanyblue/src/zbcom.gpr patch:
> -   "-gnatygO",
> +   "-gnatyO",
>
> HTH, Pascal.
>
--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
Gnoga-list mailing list
Gnoga-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gnoga-list

Re: [Gnoga-list] Zany Blue and Gnoga_Tools requirement?

[Jeremiah Breeden]

Thank you!

A curiosity:  I know David really wants to avoid Adacore GNAT GPL due to
licensing if possible.  While xmlada (and aunit) come with GNAT GPL, they
don't come with FSF GNAT on windows (at least not with TDM-GCC
distribution...does another work on Windows yet?).  Does it make sense to
have them as outside dependencies?  I've tried building xmlada with TDM-GCC
GNAT and it has other dependencies that I haven't tracked down as of yet



On Wed, Apr 13, 2016 at 3:44 PM, Pascal  wrote:

> Hello Jeremiah, sorry for the delay, thanks for reporting the issue.
>
> Actually, zbtest, testing part of Zanyblue, requires XMLAda and also AUnit.
> They are present in GNAT GPL edition so I don't have the issue.
> Well, zbtest is not needed in Gnoga so it can be suppress of the build.
> A makefile patch would be:
>  zanyblue:
> -   cd deps/zanyblue && make -C src BUILD=Debug
> +   cd deps/zanyblue && make -C src BUILD=Debug setup library
> zbmcompile
>
> I'll push on SF since it is ok on your side.
>
>
>
--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
Gnoga-list mailing list
Gnoga-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gnoga-list

Re: [Gnoga-list] Zany Blue and Gnoga_Tools requirement?

[Jeremiah Breeden]

Sure.  Out of the box, if I "make all", everything goes well until it tries
to compile zanyblue.adb:
gcc -c -gnat12 -gnatW8 -g -gnatf -gnato -gnatwale -gnatygO -gnatyo
-fstack-check -I- -gnatA
D:\Program_Files\MinGW\msys\1.0\home\Jere\gnoga-code-2016_04_09\deps\zanyblue\src\root\zanyblue.adb
zanyblue.adb:1:03: (style) incorrect line terminator
zanyblue.adb:2:72: (style) incorrect line terminator
zanyblue.adb:3:03: (style) incorrect line terminator
zanyblue.adb:4:60: (style) incorrect line terminator
zanyblue.adb:5:25: (style) incorrect line terminator

and so on until:

zanyblue.adb:99:01: (style) incorrect line terminator
zanyblue.adb:100:14: (style) incorrect line terminator
gnatmake:
"D:\Program_Files\MinGW\msys\1.0\home\Jere\gnoga-code-2016_04_09\deps\zanyblue\src\root\zanyblue.adb"
compilation error
make[1]: *** [library] Error 4
make[1]: Leaving directory
`/home/Jere/gnoga-code-2016_04_09/deps/zanyblue/src'
make: *** [zanyblue] Error 2

All the other zanyblue files before it compile fine, but this part kills
the make.  I don't have a good "fix" per say, but if I go into

\deps\zanyblue\src\zbcom.gpr

and comment out the line:

"-gnatygO",

and take out all the style checks, it compiles fine.  That's not a great
solution, but it gets me going.  Even though it compiles I still get some
warnings

gcc -c -gnaty3abcdefhiklmnOprsStu -gnat2012 -gnatW8 -g -gnata -gnatq -gnatQ
connectfour_messages.adb
connectfour_messages.adb:1:28: (style) incorrect line terminator
connectfour_messages.adb:2:03: (style) incorrect line terminator
connectfour_messages.adb:3:63: (style) incorrect line terminator
connectfour_messages.adb:4:55: (style) incorrect line terminator
connectfour_messages.adb:5:03: (style) incorrect line terminator
...
connectfour_messages.ads:39:18: (style) incorrect line terminator
connectfour_messages.ads:40:01: (style) incorrect line terminator
connectfour_messages.ads:41:26: (style) incorrect line terminator
gcc -c -gnaty3abcdefhiklmnOprsStu -gnat2012 -gnatW8 -g -gnata -gnatq -gnatQ
connectfour_messages-connectfour_strings.adb
connectfour_messages-connectfour_strings.adb:1:28: (style) incorrect line
terminator
connectfour_messages-connectfour_strings.adb:2:03: (style) incorrect line
terminator
connectfour_messages-connectfour_strings.adb:3:63: (style) incorrect line
terminator
...
connectfour_messages-connectfour_strings.ads:60:43: (style) incorrect line
terminator
connectfour_messages-connectfour_strings.ads:61:01: (style) incorrect line
terminator
connectfour_messages-connectfour_strings.ads:62:46: (style) incorrect line
terminator
gprbind connect_four.bexch
gnatbind connect_four.ali
gcc -c b__connect_four.adb
gcc connect_four.o -o connect_four.exe

Unlike the zanyblue issue, these come as warnings and don't stop
compilation, so I haven't bothered trying to fix them.

I hope this shows the issue better.
As always, this is with GNAT GPL 2015, windows 7 and 10 (both 64 bit).  I
haven't gotten the full FSF on Windows compilation to work yet, so I cannot
test that.

On Wed, Apr 13, 2016 at 3:44 PM, Pascal  wrote:

> Concerning ticket 32, could you please be more specific about "errors
> related to end of line terminators" or send the fix you apply.
> The error issue with cloning PragmaArc has been solved in previous commit
> on 2016-04-06.
>
>
>
--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
Gnoga-list mailing list
Gnoga-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gnoga-list

Re: [Gnoga-list] gnoga build fails on OSX 10.11.3

[Jeremiah Breeden]

Are you using GNAT 5.2.0 or newer?  Previous MAC versions were not working
correctly.

See:
https://sourceforge.net/p/gnoga/mailman/message/34852977/

On Mon, Apr 11, 2016 at 3:05 AM, Roger Mc Murtrie 
wrote:

> gnat --version
> GNAT GPL 2015 (20150428-49)
>
> gcc --version
> Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr
> --with-gxx-include-dir=/usr/include/c++/4.2.1
> Apple LLVM version 7.3.0 (clang-703.0.29)
> Target: x86_64-apple-darwin15.3.0
> Thread model: posix
> InstalledDir:
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
>
> I have been trying to build gnoga from git but make fails with:
> gcc -c -gnaty3abcdefhiklmnOprsStu -gnat2012 -gnatW8 -g -gnata -gnatq
> -gnatQ -fno-common gnoga.adb
> gcc -c -gnaty3abcdefhiklmnOprsStu -gnat2012 -gnatW8 -g -gnata -gnatq
> -gnatQ -fno-common gnoga-types.adb
> /var/folders/x3/tdfj8cz114g5g00zqfh__n_hgn/T//cckdrBJM.s:64963:2:
> error: ambiguous instructions require an explicit suffix (could be
> 'fisttps', or 'fisttpl')
> fisttp  -74(%rbp)
> ^
> /var/folders/x3/tdfj8cz114g5g00zqfh__n_hgn/T//cckdrBJM.s:64969:2:
> error: ambiguous instructions require an explicit suffix (could be
> 'fisttps', or 'fisttpl')
> fisttp  -74(%rbp)
> ^
> /var/folders/x3/tdfj8cz114g5g00zqfh__n_hgn/T//cckdrBJM.s:65147:2:
> error: ambiguous instructions require an explicit suffix (could be
> 'fisttps', or 'fisttpl')
> fisttp  -2(%rbp)
> ^
> /var/folders/x3/tdfj8cz114g5g00zqfh__n_hgn/T//cckdrBJM.s:65153:2:
> error: ambiguous instructions require an explicit suffix (could be
> 'fisttps', or 'fisttpl')
> fisttp  -2(%rbp)
> ^
> gprbuild: *** compilation phase failed
> make: *** [gnoga] Error 4
>
> I have tried both using the command line and using GPS.
>
> --
> Find and fix application performance issues faster with Applications
> Manager
> Applications Manager provides deep performance insights into multiple
> tiers of
> your business applications. It resolves application problems quickly and
> reduces your MTTR. Get your free trial! http://pubads.g.doubleclick.net/
> gampad/clk?id=1444514301&iu=/ca-pub-7940484522588532
> ___
> Gnoga-list mailing list
> Gnoga-list@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gnoga-list
>
--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial! http://pubads.g.doubleclick.net/
gampad/clk?id=1444514301&iu=/ca-pub-7940484522588532___
Gnoga-list mailing list
Gnoga-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gnoga-list

Re: [Gnoga-list] Zany Blue and Gnoga_Tools requirement?

[Jeremiah Breeden]

I initially built it for GNAT GPL which worked (aside from the line
terminator issue in the ticket I submitted a couple months ago [1]...but I
do a workaround for that).  I wonder if that got me past that step since
GNAT GPL comes with xmlada?

[1] https://sourceforge.net/p/gnoga/tickets/32/

On Sun, Apr 10, 2016 at 2:32 PM, Jeffrey R. Carter  wrote:

> On 04/10/2016 10:54 AM, Jeremiah Breeden wrote:
>
> gnatbind -x
> D:\Program_Files\MinGW\msys\1.0\home\Jere\gnoga-code-2016_04_09\deps\zanyblue\src\obj\zbmcompile-main.ali
> gnatlink
> D:\Program_Files\MinGW\msys\1.0\home\Jere\gnoga-code-2016_04_09\deps\zanyblue\src\obj\zbmcompile-main.ali
> -g
> D:\Program_Files\MinGW\msys\1.0\home\Jere\gnoga-code-2016_04_09\deps\zanyblue\lib\zanyblue\libzanyblue.a
> -o
> D:\Program_Files\MinGW\msys\1.0\home\Jere\gnoga-code-2016_04_09\deps\zanyblue\bin\zbmcompile.exe
> make[2]: Leaving directory
> `/home/Jere/gnoga-code-2016_04_09/deps/zanyblue/src/zbmcompile'
> make -C zbtest
> make[2]: Entering directory
> `/home/Jere/gnoga-code-2016_04_09/deps/zanyblue/src/zbtest'
> gnatmake -p -XOS=Windows_NT -XTYPE=static -XBUILD=Debug -aP../../lib/gnat
> -aP../../src -P zbtest
> warning: gnatmake -P is obsolete and will not be available in the next
> release; use gprbuild instead
> zbtest.gpr:36:06: unknown project file: "xmlada"
> gnatmake: "zbtest" processing failed
>
> I get a different error:
>
> $ git pull
>
> Already up-to-date.
>
> $ make
>
> ...
>
> cd deps/zanyblue && make -C src BUILD=Debug
>
> make[1]: Entering directory '/home/jrcarter/Code/gnoga/deps/zanyblue/src'
>
> gnatmake -p -XOS=unix -XTYPE=static -XBUILD=Debug -aP../lib/gnat -aP../src -P 
> zblib.gpr
>
> gcc-4.9 -c -gnat12 -gnatW8 -g -gnatf -gnato -gnatwale -gnatygO -gnatyo 
> -fstack-check -I- -gnatA 
> /home/jrcarter/Code/gnoga/deps/zanyblue/src/text/zanyblue-text-codecs.adb
>
> zanyblue-text-codecs.adb:260:14: "Encode_UTF8" called at line 277
>
> zanyblue-text-codecs.adb:260:14: "Find_Codecs" called at line 320
>
> gnatmake: 
> "/home/jrcarter/Code/gnoga/deps/zanyblue/src/text/zanyblue-text-codecs.adb" 
> compilation error
>
> Makefile:75: recipe for target 'library' failed
>
> make[1]: *** [library] Error 4
>
> make[1]: Leaving directory '/home/jrcarter/Code/gnoga/deps/zanyblue/src'
>
> Makefile:180: recipe for target 'zanyblue' failed
>
> make: *** [zanyblue] Error 2
>
> jrcarter@jcarter-singo-laptop:~/Code/gnoga$
>
> --
> Jeff Carter
> "My mind is a raging torrent, flooded with rivulets of
> thought, cascading into a waterfall of creative alternatives."
> Blazing Saddles
> 89
>
>
>
> --
> Find and fix application performance issues faster with Applications
> Manager
> Applications Manager provides deep performance insights into multiple
> tiers of
> your business applications. It resolves application problems quickly and
> reduces your MTTR. Get your free trial! http://pubads.g.doubleclick.net/
> gampad/clk?id=1444514301&iu=/ca-pub-7940484522588532
> ___
> Gnoga-list mailing list
> Gnoga-list@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gnoga-list
>
>
--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial! http://pubads.g.doubleclick.net/
gampad/clk?id=1444514301&iu=/ca-pub-7940484522588532___
Gnoga-list mailing list
Gnoga-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gnoga-list

Re: [Gnoga-list] Zany Blue and Gnoga_Tools requirement?

[Jeremiah Breeden]

Thanks, that's good to know.

Right now when I set my path to TMD gcc and do a "make install" when it
gets to the point of making zblib it fails on

gnatbind -x
D:\Program_Files\MinGW\msys\1.0\home\Jere\gnoga-code-2016_04_09\deps\zanyblue\src\obj\zbmcompile-main.ali
gnatlink
D:\Program_Files\MinGW\msys\1.0\home\Jere\gnoga-code-2016_04_09\deps\zanyblue\src\obj\zbmcompile-main.ali
-g
D:\Program_Files\MinGW\msys\1.0\home\Jere\gnoga-code-2016_04_09\deps\zanyblue\lib\zanyblue\libzanyblue.a
-o
D:\Program_Files\MinGW\msys\1.0\home\Jere\gnoga-code-2016_04_09\deps\zanyblue\bin\zbmcompile.exe
make[2]: Leaving directory
`/home/Jere/gnoga-code-2016_04_09/deps/zanyblue/src/zbmcompile'
make -C zbtest
make[2]: Entering directory
`/home/Jere/gnoga-code-2016_04_09/deps/zanyblue/src/zbtest'
gnatmake -p -XOS=Windows_NT -XTYPE=static -XBUILD=Debug -aP../../lib/gnat
-aP../../src -P zbtest
warning: gnatmake -P is obsolete and will not be available in the next
release; use gprbuild instead
zbtest.gpr:36:06: unknown project file: "xmlada"
gnatmake: "zbtest" processing failed
make[2]: *** [all] Error 4
make[2]: Leaving directory
`/home/Jere/gnoga-code-2016_04_09/deps/zanyblue/src/zbtest'
make[1]: *** [zbtest.app] Error 2
make[1]: Leaving directory
`/home/Jere/gnoga-code-2016_04_09/deps/zanyblue/src'
make: *** [zanyblue] Error 2

looking in the file:
\deps\zanyblue\src\zbtest\zbtest.gpr

It contains a
with "xmlada";

which is where it is failing.  I am guessing a random test file uses it.



On Sun, Apr 10, 2016 at 12:44 PM, Rabbi David Botton 
wrote:

> To my knowledge it doesn't require XMLAda (which I don't even have
> installed). Zany Blue is only needed for the Connect Four example. Nothing
> else. I'll be on top of things God willing this week and get things a bit
> cleaned up and in order and will double check this as well. It is important
> to me that nothing in the Gnoga git requires a GPL component like XMLAda.
>
> David Botton
>
>
> On Sun, Apr 10, 2016 at 12:14 PM Jeremiah Breeden <
> jeremiah.bree...@gmail.com> wrote:
>
>> Does anyone know if Gnoga requires Zany Blue or Gnoga_Tools?  I'm trying
>> to build and install Gnoga on windows for the FSF version of GNAT but it
>> keeps failing on Zany Blue due to lack of xmlada (which fails to build
>> because of another library and so on) and Gnoga_Tools due to some sort of
>> configuration issue I can't figure out.
>>
>> Right now, since both Zany blue fails to compile and gnoga_tools fails to
>> install, I have modified the Makefile to not do those.
>>
>> Will this cause a problem?  Anyone know?
>>
>> --
>> Find and fix application performance issues faster with Applications
>> Manager
>> Applications Manager provides deep performance insights into multiple
>> tiers of
>> your business applications. It resolves application problems quickly and
>> reduces your MTTR. Get your free trial! http://pubads.g.doubleclick.net/
>> gampad/clk?id=1444514301&iu=/ca-pub-7940484522588532
>> <http://pubads.g.doubleclick.net/gampad/clk?id=1444514301&iu=/ca-pub-7940484522588532>
>> ___
>> Gnoga-list mailing list
>> Gnoga-list@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/gnoga-list
>>
>
>
> --
> Find and fix application performance issues faster with Applications
> Manager
> Applications Manager provides deep performance insights into multiple
> tiers of
> your business applications. It resolves application problems quickly and
> reduces your MTTR. Get your free trial! http://pubads.g.doubleclick.net/
> gampad/clk?id=1444514301&iu=/ca-pub-7940484522588532
> ___
> Gnoga-list mailing list
> Gnoga-list@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gnoga-list
>
>
--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial! http://pubads.g.doubleclick.net/
gampad/clk?id=1444514301&iu=/ca-pub-7940484522588532___
Gnoga-list mailing list
Gnoga-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gnoga-list

[Gnoga-list] Zany Blue and Gnoga_Tools requirement?

[Jeremiah Breeden]

Does anyone know if Gnoga requires Zany Blue or Gnoga_Tools?  I'm trying to
build and install Gnoga on windows for the FSF version of GNAT but it keeps
failing on Zany Blue due to lack of xmlada (which fails to build because of
another library and so on) and Gnoga_Tools due to some sort of
configuration issue I can't figure out.

Right now, since both Zany blue fails to compile and gnoga_tools fails to
install, I have modified the Makefile to not do those.

Will this cause a problem?  Anyone know?
--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial! http://pubads.g.doubleclick.net/
gampad/clk?id=1444514301&iu=/ca-pub-7940484522588532___
Gnoga-list mailing list
Gnoga-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gnoga-list

Re: [Gnoga-list] AdaOthello port for Gnoga

[Jeremiah Breeden]

Thank you.  I emailed you the zip file (has both the Gnoga version I ported
and the original Gtk version for reference).  I deleted the build files and
the .exe to make the zip file smaller.

On Mon, Mar 14, 2016 at 8:15 PM, Rabbi David Botton 
wrote:

> You can also just e-mail me directly the zip and I can put into git.
>
> David Botton
> 
>
>
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140___
Gnoga-list mailing list
Gnoga-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gnoga-list

[Gnoga-list] AdaOthello port for Gnoga

[Jeremiah Breeden]

I've been talking with the author (Adrian Hoe) to AdaOthello, an Othello
implementation written in Ada using GtkAda as the GUI.  He has agreed to
allow me to port and release a copy of it implemented in Gnoga.

I've already mostly gotten it done now, but wanted to ask a few questions:

1.  What is the preferred method of submittal for a game port as a demo for
gnoga?  Should I just email this list with the attached files when ready?

2.  Currently, I have the application setup as a multi-connect, but I still
have the Quit button implemented to fully kill the application.  This would
be a bad idea for a website implementation, but for a demo in the gnoga
install, it might be ok?  Should I just ax the quit button altogther, leave
it as is, or do some other implementation?

3.  I basically just ported it, so I didn't go through and rename a lot of
things.  I only made the changes I needed to get it to work (I had to add
parameters to each of the procedure calls and put a lot of package level
variables into the App_Data_Type for example).  The changes were extensive,
but I still didn't change some of the names, which may not make as much
sense in my port, but I thought it would make it slightly easier to compare
old to new (despite my changes).  Example:  I changed the image type used
in GKT for the circles into just View_Type objects that were circle shaped,
but I still kept the variable name "pixmap".  They obviously aren't image
types any longer, but felt it would be easier to find them for comparison
later.  Is this OK?  Should I instead go back and name things appropriately
for the new types and implementations?

4.  License.  It looks like it fits David's prefferred type of license but
I will be the first to admit I don't know enough to be sure.  Here is a
sample file header license:


--|   Othello - The Classic Othello Game written in Ada
--|
--|   Copyright (C) 2001 Adrian Hoe (by...@users.sourceforge.net)
--|
--| Othello is free software; you can redistribute it and/or modify
--| it under the terms of the GNU General Public License as published
--| by the Free Software Foundation; either version 2 of the License,
--| or (at your option) any later version.
--|
--| This software is distributed in the hope that it will be useful,
--| and entertaining but WITHOUT ANY WARRANTY; without even the
--| implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
--| PURPOSE.  See the GNU General Public License for more details.
--|
--| You should have received a copy of the GNU General Public
--| License along with this software; if not, write to the
--| Free Software Foundation, Inc., 59 Temple Place - Suite 330,
--| Boston, MA 02111-1307, USA.
--|
--| Filename : $Source: /othello_pkg-callbacks.adb,v $
--| Author   : Adrian Hoe (byhoe)
--| Created On   : 2001/11/15
--| Last Modified By : $Author: JHB $
--| Last Modified On : $Date: 2016/03/06 09:18:25 $
--| Status   : $State: Exp $
--|


I think this means it allows for the same license as Gnoga uses.  That
sound right?

Thanks!
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785111&iu=/4140___
Gnoga-list mailing list
Gnoga-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gnoga-list

Re: [Gnoga-list] PragmArc error.

[Jeremiah Breeden]

Though I should probably ask Jeffrey:  Are all the other calls to .Element
meant to be the container primative or the package version that converts
out of bounds values to 0?

On Fri, Mar 4, 2016 at 3:57 PM, Jeremiah Breeden  wrote:

> I went in and called each function using package.method notation instead.
> I had to fix every call, so that was a pain.   I didn't finish that process
> yet as I got called off onto something, but it appeared to be taking out
> each error one by one.  I was wondering if I was misunderstanding the
> freezing rules for defining primitives, but based on Jeffrey Carter's
> response, it sounds like a compiler bug.
>
>
> On Wed, Mar 2, 2016 at 3:04 PM, Pascal  wrote:
>
>> Hello,
>>
>> I've got the following error with PragmArc compiled by GNAT GPL 2015:
>>
>> gcc -c pragmarc-unbounded_integers.adb
>> pragmarc-unbounded_integers.adb:37:21: ambiguous expression (cannot
>> resolve "Element")
>> pragmarc-unbounded_integers.adb:37:21: possible interpretation at
>> a-convec.ads:113, instance at pragmarc-unbounded_integers.ads:64
>> pragmarc-unbounded_integers.adb:37:21: possible interpretation at line 17
>> pragmarc-unbounded_integers.adb:245:54: ambiguous operand in conversion
>> pragmarc-unbounded_integers.adb:245:54: possible interpretation at line 17
>> pragmarc-unbounded_integers.adb:245:54: possible interpretation at
>> a-convec.ads:113, instance at pragmarc-unbounded_integers.ads:64
>> pragmarc-unbounded_integers.adb:245:101: ambiguous operand in conversion
>> pragmarc-unbounded_integers.adb:245:101: possible interpretation at line
>> 17
>> pragmarc-unbounded_integers.adb:245:101: possible interpretation at
>> a-convec.ads:113, instance at pragmarc-unbounded_integers.ads:64
>> pragmarc-unbounded_integers.adb:307:56: ambiguous operand in conversion
>> pragmarc-unbounded_integers.adb:307:56: possible interpretation at line 17
>> pragmarc-unbounded_integers.adb:307:56: possible interpretation at
>> a-convec.ads:113, instance at pragmarc-unbounded_integers.ads:64
>> pragmarc-unbounded_integers.adb:359:54: ambiguous expression (cannot
>> resolve "Element")
>> pragmarc-unbounded_integers.adb:359:54: possible interpretation at
>> a-convec.ads:113, instance at pragmarc-unbounded_integers.ads:64
>> pragmarc-unbounded_integers.adb:359:54: possible interpretation at line 17
>> pragmarc-unbounded_integers.adb:408:73: ambiguous operand in conversion
>> pragmarc-unbounded_integers.adb:408:73: possible interpretation at line 17
>> pragmarc-unbounded_integers.adb:408:73: possible interpretation at
>> a-convec.ads:113, instance at pragmarc-unbounded_integers.ads:64
>> pragmarc-unbounded_integers.adb:414:76: ambiguous operand in conversion
>> pragmarc-unbounded_integers.adb:414:76: possible interpretation at line 17
>> pragmarc-unbounded_integers.adb:414:76: possible interpretation at
>> a-convec.ads:113, instance at pragmarc-unbounded_integers.ads:64
>> pragmarc-unbounded_integers.adb:548:55: ambiguous expression (cannot
>> resolve "Element")
>> pragmarc-unbounded_integers.adb:548:55: possible interpretation at
>> a-convec.ads:113, instance at pragmarc-unbounded_integers.ads:64
>> pragmarc-unbounded_integers.adb:548:55: possible interpretation at line 17
>> pragmarc-unbounded_integers.adb:549:64: ambiguous expression (cannot
>> resolve "Element")
>> pragmarc-unbounded_integers.adb:549:64: possible interpretation at
>> a-convec.ads:113, instance at pragmarc-unbounded_integers.ads:64
>> pragmarc-unbounded_integers.adb:549:64: possible interpretation at line 17
>> pragmarc-unbounded_integers.adb:605:43: ambiguous expression (cannot
>> resolve "Element")
>> pragmarc-unbounded_integers.adb:605:43: possible interpretation at
>> a-convec.ads:113, instance at pragmarc-unbounded_integers.ads:64
>> pragmarc-unbounded_integers.adb:605:43: possible interpretation at line 17
>> pragmarc-unbounded_integers.adb:606:44: ambiguous expression (cannot
>> resolve "Element")
>> pragmarc-unbounded_integers.adb:606:44: possible interpretation at
>> a-convec.ads:113, instance at pragmarc-unbounded_integers.ads:64
>> pragmarc-unbounded_integers.adb:606:44: possible interpretation at line 17
>>
>>
>>
>> So I made the not satisfying quick fix below:
>>
>> --- a/pragmarc-unbounded_integers.adb
>> +++ b/pragmarc-unbounded_integers.adb
>> @@ -13,8 +13,9 @@ package body PragmARC.Unbounded_Integers is
>> Radix : constant := Digit_Value'Modulus;
>>
>> use type Digit_List;
>> +   use Digit_Lists;
>>
>

Re: [Gnoga-list] PragmArc error.

[Jeremiah Breeden]

I went in and called each function using package.method notation instead.
I had to fix every call, so that was a pain.   I didn't finish that process
yet as I got called off onto something, but it appeared to be taking out
each error one by one.  I was wondering if I was misunderstanding the
freezing rules for defining primitives, but based on Jeffrey Carter's
response, it sounds like a compiler bug.

On Wed, Mar 2, 2016 at 3:04 PM, Pascal  wrote:

> Hello,
>
> I've got the following error with PragmArc compiled by GNAT GPL 2015:
>
> gcc -c pragmarc-unbounded_integers.adb
> pragmarc-unbounded_integers.adb:37:21: ambiguous expression (cannot
> resolve "Element")
> pragmarc-unbounded_integers.adb:37:21: possible interpretation at
> a-convec.ads:113, instance at pragmarc-unbounded_integers.ads:64
> pragmarc-unbounded_integers.adb:37:21: possible interpretation at line 17
> pragmarc-unbounded_integers.adb:245:54: ambiguous operand in conversion
> pragmarc-unbounded_integers.adb:245:54: possible interpretation at line 17
> pragmarc-unbounded_integers.adb:245:54: possible interpretation at
> a-convec.ads:113, instance at pragmarc-unbounded_integers.ads:64
> pragmarc-unbounded_integers.adb:245:101: ambiguous operand in conversion
> pragmarc-unbounded_integers.adb:245:101: possible interpretation at line 17
> pragmarc-unbounded_integers.adb:245:101: possible interpretation at
> a-convec.ads:113, instance at pragmarc-unbounded_integers.ads:64
> pragmarc-unbounded_integers.adb:307:56: ambiguous operand in conversion
> pragmarc-unbounded_integers.adb:307:56: possible interpretation at line 17
> pragmarc-unbounded_integers.adb:307:56: possible interpretation at
> a-convec.ads:113, instance at pragmarc-unbounded_integers.ads:64
> pragmarc-unbounded_integers.adb:359:54: ambiguous expression (cannot
> resolve "Element")
> pragmarc-unbounded_integers.adb:359:54: possible interpretation at
> a-convec.ads:113, instance at pragmarc-unbounded_integers.ads:64
> pragmarc-unbounded_integers.adb:359:54: possible interpretation at line 17
> pragmarc-unbounded_integers.adb:408:73: ambiguous operand in conversion
> pragmarc-unbounded_integers.adb:408:73: possible interpretation at line 17
> pragmarc-unbounded_integers.adb:408:73: possible interpretation at
> a-convec.ads:113, instance at pragmarc-unbounded_integers.ads:64
> pragmarc-unbounded_integers.adb:414:76: ambiguous operand in conversion
> pragmarc-unbounded_integers.adb:414:76: possible interpretation at line 17
> pragmarc-unbounded_integers.adb:414:76: possible interpretation at
> a-convec.ads:113, instance at pragmarc-unbounded_integers.ads:64
> pragmarc-unbounded_integers.adb:548:55: ambiguous expression (cannot
> resolve "Element")
> pragmarc-unbounded_integers.adb:548:55: possible interpretation at
> a-convec.ads:113, instance at pragmarc-unbounded_integers.ads:64
> pragmarc-unbounded_integers.adb:548:55: possible interpretation at line 17
> pragmarc-unbounded_integers.adb:549:64: ambiguous expression (cannot
> resolve "Element")
> pragmarc-unbounded_integers.adb:549:64: possible interpretation at
> a-convec.ads:113, instance at pragmarc-unbounded_integers.ads:64
> pragmarc-unbounded_integers.adb:549:64: possible interpretation at line 17
> pragmarc-unbounded_integers.adb:605:43: ambiguous expression (cannot
> resolve "Element")
> pragmarc-unbounded_integers.adb:605:43: possible interpretation at
> a-convec.ads:113, instance at pragmarc-unbounded_integers.ads:64
> pragmarc-unbounded_integers.adb:605:43: possible interpretation at line 17
> pragmarc-unbounded_integers.adb:606:44: ambiguous expression (cannot
> resolve "Element")
> pragmarc-unbounded_integers.adb:606:44: possible interpretation at
> a-convec.ads:113, instance at pragmarc-unbounded_integers.ads:64
> pragmarc-unbounded_integers.adb:606:44: possible interpretation at line 17
>
>
>
> So I made the not satisfying quick fix below:
>
> --- a/pragmarc-unbounded_integers.adb
> +++ b/pragmarc-unbounded_integers.adb
> @@ -13,8 +13,9 @@ package body PragmARC.Unbounded_Integers is
> Radix : constant := Digit_Value'Modulus;
>
> use type Digit_List;
> +   use Digit_Lists;
>
> -   function Element (List : Digit_List; Index : Positive) return
> Digit_Value;
> +   --function Element (List : Digit_List; Index : Positive) return
> Digit_Value;
> -- If Index is a valid index into List, returns the value stored
> there; otherwise, returns 0
>
> procedure Insert (List : in out Digit_List; Index : in Positive; Value
> : in Digit_Value);
> @@ -30,15 +31,15 @@ package body PragmARC.Unbounded_Integers is
>   Remainder :out Unbounded_Integer);
> -- Left > 0, Right > 0.
>
> -   function Element (List : Digit_List; Index : Positive) return
> Digit_Value is
> -  -- Empty declarative part
> -   begin -- Element
> -  if Index in 1 .. List.Last_Index then
> - return List.Element (Index);
> -  end if;
> -
> -  return 0;
> -   end Element;
> +-- function Element (List :

[Gnoga-list] Make install using TDM_GCC

[Jeremiah Breeden]

I just wanted to check and make sure I am not doing something silly before
filing a ticket.

1.  I downloaded todays copy of Gnoga, the gprbuild tools on the Gnoga
site, and TDM_GCC.

2.  I installed TDM_GCC (with GNAT) and made sure it was set in my PATH
variable.

3.  Unzipped the gprbuild tools and copied them to the indicated TDM bin
directory.

4.  I unzipped gnoga, did "make all" which worked, but then followed with
my standard "make install".  This normally works fine, but here it failed.

I am running Windows 7 64 bit with the following versions of
GCC/GNAT/GPRBUILD:

Jere@Jere-PC ~/gnoga-code-2015_12_14
$ gcc --version
gcc.exe (tdm-1) 5.1.0
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


Jere@Jere-PC ~/gnoga-code-2015_12_14
$ gnat --version
GNAT 5.1.0
Copyright (C) 1996-2015, Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.


Jere@Jere-PC ~/gnoga-code-2015_12_14
$ gprbuild --version
GPRBUILD GPL 2015 (20150428) (i686-pc-mingw32)
Copyright (C) 2004-2015, Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

The error given was this:
Jere@Jere-PC ~/gnoga-code-2015_12_14
$ make install
make -C src
make[1]: Entering directory `/home/Jere/gnoga-code-2015_12_14/src'
make[1]: `gnoga-application.adb' is up to date.
make[1]: Leaving directory `/home/Jere/gnoga-code-2015_12_14/src'
cd src && gprbuild --target=mingw32 -p -Pgnoga.gpr -XPRJ_BUILD=Release
-XPRJ_TARGET=Windows -XAtomic
_Access=GCC-long-offsets
"libgnoga.a" up to date
cd lib && attrib -R
cd src && gprbuild --target=mingw32 -p -Pgnoga.gpr -XPRJ_TARGET=Windows
-XAtomic_Access=GCC-long-off
sets
"libgnoga.a" up to date
cd deps/simple_components && ar rc ../../lib/libgnoga.a *.o
cd deps/simple_components/xpm && ar rc ../../../lib/libgnoga.a *.o
rm include/*.ad?
cp src/*.ad[sb] include
cp src/gnoga-server-model-table.adb include
cp deps/simple_components/*.ads include
cp deps/simple_components/*.ali lib
cp deps/simple_components/xpm/*.ads include
cp deps/simple_components/xpm/*.ali lib
cd lib && attrib +R
cd tools && gprbuild --target=mingw32 -p -Ptools.gpr -XPRJ_TARGET=Windows
gcc -c -gnaty3abcdefhiklmnOprsStu -gnat2012 -gnatW8 -g -gnata -gnatq -gnatQ
gnoga_make-main.adb
gcc -c -gnaty3abcdefhiklmnOprsStu -gnat2012 -gnatW8 -g -gnata -gnatq -gnatQ
gnoga_doc-main.adb
gcc -c -gnaty3abcdefhiklmnOprsStu -gnat2012 -gnatW8 -g -gnata -gnatq -gnatQ
gnoga_make.adb
gcc -c -gnaty3abcdefhiklmnOprsStu -gnat2012 -gnatW8 -g -gnata -gnatq -gnatQ
gnoga_doc.adb
gcc -c -gnaty3abcdefhiklmnOprsStu -gnat2012 -gnatW8 -g -gnata -gnatq -gnatQ
gnoga_doc-token.adb
gprbind gnoga_make-main.bexch
gnatbind gnoga_make-main.ali
gcc -c b__gnoga_make-main.adb
gprbind gnoga_doc-main.bexch
gnatbind gnoga_doc-main.ali
gcc -c b__gnoga_doc-main.adb
gcc gnoga_make-main.o -o gnoga_make.exe
gcc gnoga_doc-main.o -o gnoga_doc.exe
touch deps/simple_components/strings_edit-text_edit.o
cd src && gprinstall -f --prefix=/c/TDM-GCC-32/bin/.. -p gnoga.gpr
-XPRJ_BUILD=Release
Install project Gnoga
cd tools && gprinstall -f --prefix=/c/TDM-GCC-32/bin/.. -p --mode=usage
--install-name=tools tools.g
pr
Install project Tools
file C:\MinGW\msys\1.0\home\Jere\gnoga-code-2015_12_14\bin\gnoga_make does
not exist, build may not
be complete
make: *** [install] Error 1

I checked and the file is there at that location, though it has a ".exe"
extension:  gnoga_make.exe

Am I doing everything legit, or am I forgetting something simple?  Should I
file a ticket?
--
___
Gnoga-list mailing list
Gnoga-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gnoga-list