Hi Paul,
thanks a lot. Sorry, but I missed your suggestion.
Now fixed in *SVN 1753*.
Best Regards,
Jürgen
On 2/14/24 15:37, Paul Rockwell wrote:
To get the file modification time, you query the st_mtimespec.tv_sec
field of the struct stat returned by stat(). Both platforms are
returning the
To get the file modification time, you query the st_mtimespec.tv_sec field of
the struct stat returned by stat(). Both platforms are returning the file
modification/access/status as a struct timestat to support both second and
millisecond resolution. For some reason known only to Apple those fi
Hi Paul,
thanks. Could you please have a look at your*/usr/include/.../stat.h*
file and let me know how to get the modification time (or a macro
that tells if it is present or absent)?
Thanks,
Jürgen
On 2/13/24 19:56, Paul Rockwell wrote:
When compiling SVN 1752 on macOS, an error is thrown b
Thanks for the explanation--very much appreciated.
I more or less stumbled onto 1. and am using that in every relevant
circumstance, but I'll revise to 4. (I can't generally use 5. because
some of the strings use what I assume are non-ASCII characters like "←".)
Thanks again,
Chris
On 6/7/
Hi Chris,
wrapping arbitrary (= UTF8-encoded) strings into UTF8_string first is
the proper way to go. Consider the differences between:
*
**1. UCS_string yyy(UTF8_string(xxx)); // almost proper, but
ambiguous (most vexing parse error)**
**2. UCS_string yyy(xxx); // now privat
Yeah, I saw your comment in one of the .hh files. What I did was wrap
all the edif ASCII strings in UTF8_string() calls. That works, but if
it's circumventing what you're trying to do, let me know and I'll think
of something else.
Even after a lot of years, I'm still not sure of the differenc
Hi,
sorry for that. The reason for making it private is to entirely prevent
its usage.
The former implementation of of it only worked for ASCII strings. There was
a note about that in the header file, but I have seen quite a few incorrect
usages of it (read: with UTF8-encoded strings) which the
Glad it works.
It's probably a better idea to run ./configure before building. That way
the Makefiles will exactly match your environment. The downside of
having a choice of Linux distros is that they're all a little different.
--cm
On 6/6/23 15:34, Christian Robert wrote:
Hi Chris,
work
Hi Chris,
work as well as it used to !
many thanks for fixing this. I had to edit the generated ./libtool
and change
from:
# Which release of libtool.m4 was used?
macro_version=2.4.7
macro_revision=2.4.7
to:
# Which release of libtool.m4 was used?
macro_version=2.4.6
macro_revision=2.4.6
Hi, Xtian,
Just pushed a fix for edif if you want to give it a try. Works for me
on SVN 1706 and yesterday's SVN 1708.
--cm
On 6/5/23 03:33, Christian Robert wrote:
SVN 1704 completely broke libedif
Juergen made UCS_string (const char *) a private member of the class
so a lot of compile e
On 5/26/23, Blake McBride wrote:
> When I got myself in a mess with GIT, I requested help from the local "GIT
> expert." However, more often than not, they couldn't figure it out either.
Never did that in my life. I always rely on documentation, books and
myself. I'm self taught :) From my exper
Here is the thing for me. In the beginning, I read a little bit about
subversion. Its model, at least from a user's perspective, was simple and
straightforward. I was able to make use of it immediately. As my needs
expanded, I found simple solutions with subversion. I never got caught up
in a
On 5/26/23, Dr. Jürgen Sauermann wrote:
> I would like to share another anecdote with you.
Thanks for sharing. Now we have some experience in common and not only
in technology ;) Sorry that it happened to you. I believe that such
society is broken, but that's another matter.
Git has a distribute
I would like to share another anecdote with you.
Some years ago I worked for a company that forced me to use
git. I used to work from my home office and commit my changes
to the company's git repository. Needless to say that I use SVN
in my home office and I admit that I am not a git expert, not
Hi,
I am using a two-step approach in maintaining GNU APL. It uses
2 different SVN servers, one local SVN server located on my local
LAN,
the other somewhere else (at savannah.org).
1. The first step is committing changes from my local build
Point taken!
"Benign" is a relative concept... I meant it only in the sense that the
compiles and linking would work.
I would never advocate that displaying an incorrect version is a good
thing. I just don't have that problem yet... If I don't trust the build,
then the version doesn't matte
When APL starts it displays the Welcome page which lists the purported svn.
If it displays an incorrect one then the natural assumption is that the git
clone did not download the latest svn.
That’s what I thought when I did the test to verify your Quad Plot syntax
error.
Doesn’t seem benign to
Hi Louis,
thanks, fixed in SVN 1425.
Best Regards,
Jürgen
On 1/30/21 6:32 PM, lchretien--- via
Bugs and suggestions for GNU APL wrote:
From the latest SVN, 1423:
g++
-DHAVE_CONFI
n 132
From: Bug-apl [bug-apl-bounces+callab5=rpi@gnu.org] on behalf of
lchretien--- via Bugs and suggestions for GNU APL [bug-apl@gnu.org]
Sent: Monday, January 25, 2021 2:45 PM
To: Louis Chretien via Bugs and suggestions for GNU APL
Subject: Re: SVN 1404 warning on Mac OS
Appar
Apparently, “autoreconf” does not exist on Mac OS X.
Here’s my rebuild script:
cd ~/Subversion
rm -rf apl
mkdir apl
cd apl
cp -rp ../gnu-apl.svn/. .
./configure
make
> On Jan 25, 2021, at 05:34, Dr. Jürgen Sauermann
> wrote:
>
> Hi Louis,
>
> the way you do it looks OK (provided that you ru
Hi Louis,
the way you do it looks OK (provided that you run ./configure
or even better autoreconf ; ./configure
after svn up).
However, there were many "using namespace std;" declarations in the
source files (many of them
in header files so that they aff
Actually, I keep the source code in two directories: the apl-svn/ that I update
from you, and an apl/ folder.
Every time I update from SVN, I delete the apl/ folder and copy everything from
the apl-svn one. So I always start completely clean.
Unless I missed something?
> On Jan 20, 2021, at 13
Hi Louis,
the reson that the you got the warning only once is most likely
you did no make clean
(actually, you should) after svn up, so only Quad_XML.cc
was recompiled.
I have removed all instances of "using namespace std" now. SVN 1412.
How about disabling that specific warning?
Den tis 19 jan. 2021 01:51Dr. Jürgen Sauermann
skrev:
> Hi Louis,
>
> thanks, lookd like the compiler guys were again busy with implementing new
> stupid warnings.
>
> I remember that some time ago *gcc* would complain the other way around
> (when
> "us
> On Jan 18, 2021, at 12:21, Dr. Jürgen Sauermann
> wrote:
>
> Hi Louis,
>
> thanks, lookd like the compiler guys were again busy with implementing new
> stupid warnings.
>
> I remember that some time ago gcc would complain the other way around (when
> "using namespace std" was missing as o
Hi Louis,
thanks, lookd like the compiler guys were again busy with
implementing new stupid warnings.
I remember that some time ago gcc would complain the other
way around (when
"using namespace std" was missing as opposed to being present).
Hi Bill,
thanks, fixed in SVN 1378.
It now gives a RAMK ERROR deep down in your APL code, so I believe
GNU APL is not the culprit.
Best Regards,
Jürgen
On 12/14/20 11:50 PM, Bill Daly wrote:
I'm
sending a log of my test
Looks good. Thank you for all your work on this.
Bill
On 12/9/20 7:04 AM, Dr. Jürgen Sauermann wrote:
Hi Bill,
thanks, fixed in SVN 1371.
Best Regards,
Jürgen
On 12/9/20 4:24 AM, Bill Heagy wrote:
Before this change:
⍴⍴(1 2)+¨⊂ 3 4 5
1
⍴⍴(,2)+¨⊂ 3 4 5
1
which is what I expect
Hi Bill,
thanks, fixed in SVN 1371.
Best Regards,
Jürgen
On 12/9/20 4:24 AM, Bill Heagy wrote:
Before
this change:
⍴⍴(1 2)+¨⊂ 3 4 5
1
⍴⍴(,2)+¨⊂ 3 4 5
1
which is what I exp
That works. Thanks!
~Brian
On 2020-05-03 1:29 PM, Dr. Jürgen Sauermann wrote:
Hi Brian,
I see. Hopefully *SVN 1282*works better.
Best Regards,
Jürgen
On 5/3/20 7:10 PM, Brian Callahan wrote:
Hi Jürgen --
Now I get this.
~Brian
Quad_RVAL.cc:483:6: error: member initializer 'N' does not n
Hi Brian,
I see. Hopefully SVN
1282 works
better.
Best Regards,
Jürgen
On 5/3/20 7:10 PM, Brian Callahan
wrote:
Hi Jürgen --
Now I get this.
Hi Jürgen --
Now I get this.
~Brian
Quad_RVAL.cc:483:6: error: member initializer 'N' does not name a
non-static data member or base class
N(8)
^~~~
Quad_RVAL.cc:488:12: error: out-of-line definition of 'do_eval_B' does
not match any declaration in 'Quad_RVAL'
Quad_RVAL::do_eval_B
Hi Brian,
thanks, Hopefully fixed in SVN 1281.
Best Rgeards,
Jürgen
On 5/3/20 5:16 PM, Brian Callahan
wrote:
Hello --
The follow build error occurred with SVN 1278. OpenBSD/amd64,
clang++ as compiler
Hi Jürgen:
I did a fresh svn co; ./configure; make; clean; make
Well it seems makeinfo is in fact installed on my machine:
> Gandalf:apl-svn pteeson$
> Last login: Sat Apr 25 15:30:20 on ttys000
> Gandalf:apl-svn pteeson$ which makeinfo
> /usr/bin/makeinfo
> Gandalf:apl-svn pteeson$
But no mat
Hi Peter,
I believe that apl.html should not be removed
rather than removing libapl.html as well.
This is because removing an html file in make clean
triggers issue 2. below on machines that
do not have makeinfo installed.
Hopefully fixed in SVN
Hi Jürgen:
A couple of very minor things re doc directory:
1.
Making clean in doc
test -z "apl.dvi apl.pdf apl.ps apl.html" \
|| rm -rf apl.dvi apl.pdf apl.ps apl.html
Q: should libapl.html also be rm'd?
2.
Gandalf:apl-svn pteeson$ make
make all-recursive
Making all in doc
/bin/sh /Volum
Hi Jürgen:
> "your compiler apparently pretends to be g++"
ROTFLOL
Yes no need to push this any further…..
respect…
Peter
Hi Peter,
great!
I believe we can't do much about the remaining -rdynamic because your
compiler
apparently pretends to be g++ but then warns about a valid g++ argument
being (un-)used.
/// Jürgen
On 04/24/2014 02:35 PM, Peter Teeson wrote:
/bin/sh ../../libtool --tag=CXX --mode=compile g++
/bin/sh ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I.
-I../.. -I/usr/local/include -rdynamic -g -O2 -MT util.lo -MD -MP -MF
.deps/util.Tpo -c -o util.lo util.cc
libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../.. -I/usr/local/include
-rdynamic -g -O2 -MT util.lo -MD -MP -MF .
39 matches
Mail list logo
