You can subscribe to this list here.
2004 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
(1) |
Jun
(1) |
Jul
|
Aug
|
Sep
(1) |
Oct
(2) |
Nov
|
Dec
(10) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2005 |
Jan
(9) |
Feb
(10) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
(18) |
Dec
(2) |
2006 |
Jan
(5) |
Feb
|
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(5) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(3) |
2008 |
Jan
|
Feb
|
Mar
(22) |
Apr
|
May
(2) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
(7) |
Aug
(10) |
Sep
|
Oct
|
Nov
(4) |
Dec
|
2010 |
Jan
|
Feb
|
Mar
|
Apr
(10) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2011 |
Jan
|
Feb
(1) |
Mar
(6) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2014 |
Jan
(1) |
Feb
(10) |
Mar
(15) |
Apr
(11) |
May
(13) |
Jun
(4) |
Jul
|
Aug
(1) |
Sep
|
Oct
(1) |
Nov
(1) |
Dec
(2) |
2015 |
Jan
|
Feb
(3) |
Mar
|
Apr
|
May
(7) |
Jun
(4) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(15) |
2016 |
Jan
(35) |
Feb
(4) |
Mar
|
Apr
(3) |
May
(3) |
Jun
(8) |
Jul
(3) |
Aug
(2) |
Sep
(4) |
Oct
|
Nov
(10) |
Dec
(7) |
2017 |
Jan
|
Feb
|
Mar
(2) |
Apr
(1) |
May
(10) |
Jun
(14) |
Jul
(10) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2018 |
Jan
(3) |
Feb
(1) |
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(3) |
Oct
|
Nov
|
Dec
(3) |
2019 |
Jan
|
Feb
|
Mar
|
Apr
(5) |
May
(5) |
Jun
|
Jul
(4) |
Aug
|
Sep
|
Oct
|
Nov
(5) |
Dec
(1) |
2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(9) |
Jul
|
Aug
(1) |
Sep
|
Oct
(6) |
Nov
|
Dec
(5) |
2021 |
Jan
(11) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Bruce & B. R. <br...@dc...> - 2021-01-11 11:24:44
|
Good evening Clinton and Jafar, I hope this finds you both well. I have done a quick run using gdb ../../bin/icont with the paramaters set to -o unicon main Gdb gave the following response Translating: main.icn: main No errors Linking: unigram.action.icn: "treenode": inconsistent redeclaration Program received signal SIGSEGV, Segmentation fault. 0x000000000040fe7f in gencode () I haven't been able to look at this further. There are a number of other messages related to the following Starting program: /home/bruce/src/git/local/unicon/bin/icont -o unicon main Missing separate debuginfos, use: yum debuginfo-install glibc-2.28-72.el8_1.1.x86_64 warning: Loadable section ".note.gnu.property" outside of ELF segments [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". and Missing separate debuginfos, use: yum debuginfo-install SDL-1.2.15-36.el8_1.x86_64 bzip2-libs-1.0.6-26.el8.x86_64 expat-2.2.5-3.el8.x86_64 fontconfig-2.13.1-3.el8.x86_64 freetype-2.9.1-4.el8.x86_64 ftgl-2.1.3-0.21.rc5.el8.x86_64 libX11-1.6.7-1.el8.x86_64 libXau-1.0.8-13.el8.x86_64 libXext-1.3.3-9.el8.x86_64 libXft-2.3.2-10.el8.x86_64 libXrender-0.9.10-7.el8.x86_64 libatomic-8.3.1-4.5.el8.x86_64 libgcc-8.3.1-4.5.el8.x86_64 libglvnd-1.0.1-0.9.git5baa1e5.el8.x86_64 libglvnd-glx-1.0.1-0.9.git5baa1e5.el8.x86_64 libiodbc-3.52.13-1.el8.x86_64 libjpeg-turbo-1.5.3-10.el8.x86_64 libogg-1.3.2-10.el8.x86_64 libpng-1.6.34-5.el8.x86_64 libstdc++-8.3.1-4.5.el8.x86_64 libuuid-2.32.1-17.el8.x86_64 libvorbis-1.3.6-2.el8.x86_64 libxcb-1.13-5.el8.x86_64 libxcrypt-4.1.1-4.el8.x86_64 mesa-libGLU-9.0.0-15.el8.x86_64 openal-soft-1.18.2-7.el8.x86_64 openssl-libs-1.1.1c-2.el8.x86_64 zlib-1.2.11-10.el8.x86_64 As I am not proficient with gdb, I have not spent any time looking at what these messages mean. Any directions would be appreciated so that I can collect the required information that you need here. regards and blessings Bruce Rennie On 9/1/21 8:42 pm, Bruce & Breeanna Rennie wrote: > Good evening Clinton, > > This is the data from the configure script: > > -------------------------------------------------- > Unicon 13.3 Configuration Summary > -------------------------------------------------- > *** Build Environment > Host : linux-gnu (x86_64_linux) CentOS Linux 8 > CC : gcc > CFLAGS : -O2 -fno-omit-frame-pointer -fno-strict-aliasing > -Wno-parentheses-equality > CPPFLAGS : -m64 -I/usr/local/include -I/usr/local > -I/usr/include/freetype2 > LDFLAGS : -m64 -rdynamic -L/usr/local/lib > LIBS : -lssl -lcrypto -lpthread -liodbc -lopenal -lSDL > -lvorbisfile -lvorbis -logg -ldl -lftgl -lGLU -lGL -lm -lpng -ljpeg > -lXft -lfreetype -lX11 -lz -lcrypt -lstdc++ > CXX : g++ (Required only with FTGL and VOIP) > CXXFLAGS : -g -O2 > prefix : /home/bruce/unicon > Verbose : no > Debug : no > Devmode : no > Revision : 6227_28662317 > > *** Features (+Available -Missing !Disabled) > + Compression : +ZLIB > + Graphics : +X11 +JPG +PNG +XFT +Freetype > + Graphics3D : +OpenGL +GLU +FTGL > + Concurrency : +pthread > - Audio : +OpenAL -alut ( +ogg +vorbis ) | ( -SDL > -SMPEG ) > - VOIP : -voip -jvoip -jthread -jrtp > + Database : +iodbc > + SSL : +ssl > + Plugins > + Compiler: no concurrency > + Patterns > + Overloading > > and this is from the gcc version > > [bruce@Bruce unicon]$ gcc --version > gcc (GCC) 8.3.1 20190507 (Red Hat 8.3.1-4) > > regards and blessings > > Bruce Rennie > > On 9/1/21 3:37 pm, Jeffery, Clinton wrote: >> Hi Bruce, >> >> It could be related to the rt directory setup, but it is somewhat >> unlikely to be that. I forget if you are proficient in debugging C >> code and want to take a stab at it with gdb or valgrind. If you'd >> rather, you might put all your sources in a .zip file and share it so >> we can see if your bug is reproducible. Also, if it is convenient >> please remind me exactly what operating system, compiler version, and >> CFLAGS your icont was built with. >> >> Cheers, >> Clint >> >> On Fri, Jan 8, 2021 at 9:29 PM Bruce & Breeanna Rennie >> <br...@dc... <mailto:br...@dc...>> wrote: >> >> Good afternoon Clinton and Jafar, >> >> I hope this finds you well on the beautiful summers day. >> >> With the latest git (bar the last two commits) I get the following >> problem arising with the icont program. >> >> [bruce@Bruce unicon]$ ../../bin/icont -o unicon main >> Translating: >> main.icn: >> main >> No errors >> Linking: >> unigram.action.icn: "treenode": inconsistent redeclaration >> Segmentation fault (core dumped) >> >> I am making some the relevant modifications for the new form of >> parsing >> actions. >> >> If I use an older icont created on the 2 Dec 2020, I get the >> following >> >> [bruce@Bruce unicon]$ icont -o unicon main >> Translating: >> main.icn: >> main >> No errors >> Linking: >> >> Could this problem be related to the new rt directory setup? >> >> regards and blessing >> >> Bruce Rennie >> >> >> >> _______________________________________________ >> Unicon-ldif mailing list >> Uni...@li... >> https://lists.sourceforge.net/lists/listinfo/unicon-ldif > > > > _______________________________________________ > Unicon-ldif mailing list > Uni...@li... > https://lists.sourceforge.net/lists/listinfo/unicon-ldif |
From: Bruce & B. R. <br...@dc...> - 2021-01-09 10:44:12
|
Good evening Clinton, This is the data from the configure script: -------------------------------------------------- Unicon 13.3 Configuration Summary -------------------------------------------------- *** Build Environment Host : linux-gnu (x86_64_linux) CentOS Linux 8 CC : gcc CFLAGS : -O2 -fno-omit-frame-pointer -fno-strict-aliasing -Wno-parentheses-equality CPPFLAGS : -m64 -I/usr/local/include -I/usr/local -I/usr/include/freetype2 LDFLAGS : -m64 -rdynamic -L/usr/local/lib LIBS : -lssl -lcrypto -lpthread -liodbc -lopenal -lSDL -lvorbisfile -lvorbis -logg -ldl -lftgl -lGLU -lGL -lm -lpng -ljpeg -lXft -lfreetype -lX11 -lz -lcrypt -lstdc++ CXX : g++ (Required only with FTGL and VOIP) CXXFLAGS : -g -O2 prefix : /home/bruce/unicon Verbose : no Debug : no Devmode : no Revision : 6227_28662317 *** Features (+Available -Missing !Disabled) + Compression : +ZLIB + Graphics : +X11 +JPG +PNG +XFT +Freetype + Graphics3D : +OpenGL +GLU +FTGL + Concurrency : +pthread - Audio : +OpenAL -alut ( +ogg +vorbis ) | ( -SDL -SMPEG ) - VOIP : -voip -jvoip -jthread -jrtp + Database : +iodbc + SSL : +ssl + Plugins + Compiler: no concurrency + Patterns + Overloading and this is from the gcc version [bruce@Bruce unicon]$ gcc --version gcc (GCC) 8.3.1 20190507 (Red Hat 8.3.1-4) regards and blessings Bruce Rennie On 9/1/21 3:37 pm, Jeffery, Clinton wrote: > Hi Bruce, > > It could be related to the rt directory setup, but it is somewhat > unlikely to be that. I forget if you are proficient in debugging C > code and want to take a stab at it with gdb or valgrind. If you'd > rather, you might put all your sources in a .zip file and share it so > we can see if your bug is reproducible. Also, if it is convenient > please remind me exactly what operating system, compiler version, and > CFLAGS your icont was built with. > > Cheers, > Clint > > On Fri, Jan 8, 2021 at 9:29 PM Bruce & Breeanna Rennie > <br...@dc... <mailto:br...@dc...>> wrote: > > Good afternoon Clinton and Jafar, > > I hope this finds you well on the beautiful summers day. > > With the latest git (bar the last two commits) I get the following > problem arising with the icont program. > > [bruce@Bruce unicon]$ ../../bin/icont -o unicon main > Translating: > main.icn: > main > No errors > Linking: > unigram.action.icn: "treenode": inconsistent redeclaration > Segmentation fault (core dumped) > > I am making some the relevant modifications for the new form of > parsing > actions. > > If I use an older icont created on the 2 Dec 2020, I get the following > > [bruce@Bruce unicon]$ icont -o unicon main > Translating: > main.icn: > main > No errors > Linking: > > Could this problem be related to the new rt directory setup? > > regards and blessing > > Bruce Rennie > > > > _______________________________________________ > Unicon-ldif mailing list > Uni...@li... > https://lists.sourceforge.net/lists/listinfo/unicon-ldif |
From: Bruce & B. R. <br...@dc...> - 2021-01-09 07:44:38
|
Good evening Clinton and Jafar, Just a note of clarification. The error is occurring when trying to build the new Unicon compiler. So I can try running icont under gdb. When I can, I'll get the other info for you, Clinton. My o/s is Centos 8 regards and blessing to you and your families Bruce Rennie On 9/1/21 4:02 pm, Jafar Al-Gharaibeh wrote: > I agree that this is best solved using gdb. It might be easiest to > using unicon -E first to produce a file that you can invoke icont > directly on. You can then run icont under gdb to catch the segfault. > > Cheers, > Jafar > > On Fri, Jan 8, 2021 at 11:37 PM Jeffery, Clinton > <cli...@nm... <mailto:cli...@nm...>> wrote: > > Hi Bruce, > > It could be related to the rt directory setup, but it is somewhat > unlikely to be that. I forget if you are proficient in debugging > C code and want to take a stab at it with gdb or valgrind. If > you'd rather, you might put all your sources in a .zip file and > share it so we can see if your bug is reproducible. Also, if it is > convenient please remind me exactly what operating system, > compiler version, and CFLAGS your icont was built with. > > Cheers, > Clint > > On Fri, Jan 8, 2021 at 9:29 PM Bruce & Breeanna Rennie > <br...@dc... <mailto:br...@dc...>> wrote: > > Good afternoon Clinton and Jafar, > > I hope this finds you well on the beautiful summers day. > > With the latest git (bar the last two commits) I get the > following > problem arising with the icont program. > > [bruce@Bruce unicon]$ ../../bin/icont -o unicon main > Translating: > main.icn: > main > No errors > Linking: > unigram.action.icn: "treenode": inconsistent redeclaration > Segmentation fault (core dumped) > > I am making some the relevant modifications for the new form > of parsing > actions. > > If I use an older icont created on the 2 Dec 2020, I get the > following > > [bruce@Bruce unicon]$ icont -o unicon main > Translating: > main.icn: > main > No errors > Linking: > > Could this problem be related to the new rt directory setup? > > regards and blessing > > Bruce Rennie > > > > _______________________________________________ > Unicon-ldif mailing list > Uni...@li... > https://lists.sourceforge.net/lists/listinfo/unicon-ldif |
From: Jeffery, C. <cli...@nm...> - 2021-01-09 06:06:07
|
Hi Bruce, It could be related to the rt directory setup, but it is somewhat unlikely to be that. I forget if you are proficient in debugging C code and want to take a stab at it with gdb or valgrind. If you'd rather, you might put all your sources in a .zip file and share it so we can see if your bug is reproducible. Also, if it is convenient please remind me exactly what operating system, compiler version, and CFLAGS your icont was built with. Cheers, Clint On Fri, Jan 8, 2021 at 9:29 PM Bruce & Breeanna Rennie <br...@dc...> wrote: > Good afternoon Clinton and Jafar, > > I hope this finds you well on the beautiful summers day. > > With the latest git (bar the last two commits) I get the following > problem arising with the icont program. > > [bruce@Bruce unicon]$ ../../bin/icont -o unicon main > Translating: > main.icn: > main > No errors > Linking: > unigram.action.icn: "treenode": inconsistent redeclaration > Segmentation fault (core dumped) > > I am making some the relevant modifications for the new form of parsing > actions. > > If I use an older icont created on the 2 Dec 2020, I get the following > > [bruce@Bruce unicon]$ icont -o unicon main > Translating: > main.icn: > main > No errors > Linking: > > Could this problem be related to the new rt directory setup? > > regards and blessing > > Bruce Rennie > |
From: Jafar Al-G. <to....@gm...> - 2021-01-09 06:03:00
|
I agree that this is best solved using gdb. It might be easiest to using unicon -E first to produce a file that you can invoke icont directly on. You can then run icont under gdb to catch the segfault. Cheers, Jafar On Fri, Jan 8, 2021 at 11:37 PM Jeffery, Clinton <cli...@nm...> wrote: > Hi Bruce, > > It could be related to the rt directory setup, but it is somewhat unlikely > to be that. I forget if you are proficient in debugging C code and want to > take a stab at it with gdb or valgrind. If you'd rather, you might put all > your sources in a .zip file and share it so we can see if your bug is > reproducible. Also, if it is convenient please remind me exactly what > operating system, compiler version, and CFLAGS your icont was built with. > > Cheers, > Clint > > On Fri, Jan 8, 2021 at 9:29 PM Bruce & Breeanna Rennie < > br...@dc...> wrote: > >> Good afternoon Clinton and Jafar, >> >> I hope this finds you well on the beautiful summers day. >> >> With the latest git (bar the last two commits) I get the following >> problem arising with the icont program. >> >> [bruce@Bruce unicon]$ ../../bin/icont -o unicon main >> Translating: >> main.icn: >> main >> No errors >> Linking: >> unigram.action.icn: "treenode": inconsistent redeclaration >> Segmentation fault (core dumped) >> >> I am making some the relevant modifications for the new form of parsing >> actions. >> >> If I use an older icont created on the 2 Dec 2020, I get the following >> >> [bruce@Bruce unicon]$ icont -o unicon main >> Translating: >> main.icn: >> main >> No errors >> Linking: >> >> Could this problem be related to the new rt directory setup? >> >> regards and blessing >> >> Bruce Rennie >> > |
From: Bruce & B. R. <br...@dc...> - 2021-01-09 04:29:47
|
Good afternoon Clinton and Jafar, I hope this finds you well on the beautiful summers day. With the latest git (bar the last two commits) I get the following problem arising with the icont program. [bruce@Bruce unicon]$ ../../bin/icont -o unicon main Translating: main.icn: main No errors Linking: unigram.action.icn: "treenode": inconsistent redeclaration Segmentation fault (core dumped) I am making some the relevant modifications for the new form of parsing actions. If I use an older icont created on the 2 Dec 2020, I get the following [bruce@Bruce unicon]$ icont -o unicon main Translating: main.icn: main No errors Linking: Could this problem be related to the new rt directory setup? regards and blessing Bruce Rennie |
From: Bruce & B. R. <br...@dc...> - 2021-01-07 23:44:58
|
Good morning Clinton, Any of these options would be acceptable as far as I am concerned. regards Bruce Rennie On 8/1/21 6:08 am, Jeffery, Clinton (jef...@ui...) wrote: > If it was on a UNIX-based system, it might be due to the user's umask > settings. On some OS'es these settings are surprising by default. > The paranoid thing to do would be to fix the Makefile to either set > the required umask or explicitly chmod files per Bruce's workaround. > A lazier thing to do might be to check for problematic umask and > instruct the user to fix it if needed. Or just document the > requirement in the README. > > ------------------------------------------------------------------------ > *From:* Jafar Al-Gharaibeh <to....@gm...> > *Sent:* Thursday, January 7, 2021 11:55 AM > *To:* Bruce & Breeanna Rennie <br...@dc...> > *Cc:* uni...@li... > <uni...@li...> > *Subject:* Re: [Unicon-ldif] Permissions problem with new rt directory > Hi Bruce, > > Did this happen with source code checked out of GitHub git repo ? > Or from prepackaged sources ? > > In either case, I don't know what would cause this as none of these > files are marked as read-only AFAIK. I haven't seen this error on any > of the systems I test on nor I did on the CI system. > > Regards, > Jafar > > On Wed, Jan 6, 2021 at 6:41 AM Bruce & Breeanna Rennie > <br...@dc... <mailto:br...@dc...>> wrote: > > Good evening Jafar, > > I hope this finds you well for the start of the New Year. > > I don't know if this is related to my system alone but I have > found the > following problem with running the make for the latest unicon > download. > When it gets to the gdbm directory, a couple of files are copied > to the > rt directory. If you rerun the make, there is a failure with a > copy of > the gdbm.h file as the destination is now read-only. I have fixed > this > on my system by running chmod against all files under rt. This > appears > to fix the problem. > > regards and blessing to you and your family > > Bruce Rennie > > > > _______________________________________________ > Unicon-ldif mailing list > Uni...@li... > https://lists.sourceforge.net/lists/listinfo/unicon-ldif |
From: Bruce & B. R. <br...@dc...> - 2021-01-07 23:42:51
|
Good morning Jafar, This happened with source code checked out of GiHub. I did a merge with the upstream/master and rebuilt. regards Bruce Rennie On 8/1/21 5:55 am, Jafar Al-Gharaibeh wrote: > Hi Bruce, > > Did this happen with source code checked out of GitHub git repo ? > Or from prepackaged sources ? > > In either case, I don't know what would cause this as none of these > files are marked as read-only AFAIK. I haven't seen this error on any > of the systems I test on nor I did on the CI system. > > Regards, > Jafar > > On Wed, Jan 6, 2021 at 6:41 AM Bruce & Breeanna Rennie > <br...@dc... <mailto:br...@dc...>> wrote: > > Good evening Jafar, > > I hope this finds you well for the start of the New Year. > > I don't know if this is related to my system alone but I have > found the > following problem with running the make for the latest unicon > download. > When it gets to the gdbm directory, a couple of files are copied > to the > rt directory. If you rerun the make, there is a failure with a > copy of > the gdbm.h file as the destination is now read-only. I have fixed > this > on my system by running chmod against all files under rt. This > appears > to fix the problem. > > regards and blessing to you and your family > > Bruce Rennie > > > > _______________________________________________ > Unicon-ldif mailing list > Uni...@li... > https://lists.sourceforge.net/lists/listinfo/unicon-ldif |
From: Jeffery, C. (<jef...@ui...> - 2021-01-07 20:47:41
|
If it was on a UNIX-based system, it might be due to the user's umask settings. On some OS'es these settings are surprising by default. The paranoid thing to do would be to fix the Makefile to either set the required umask or explicitly chmod files per Bruce's workaround. A lazier thing to do might be to check for problematic umask and instruct the user to fix it if needed. Or just document the requirement in the README. ________________________________ From: Jafar Al-Gharaibeh <to....@gm...> Sent: Thursday, January 7, 2021 11:55 AM To: Bruce & Breeanna Rennie <br...@dc...> Cc: uni...@li... <uni...@li...> Subject: Re: [Unicon-ldif] Permissions problem with new rt directory Hi Bruce, Did this happen with source code checked out of GitHub git repo ? Or from prepackaged sources ? In either case, I don't know what would cause this as none of these files are marked as read-only AFAIK. I haven't seen this error on any of the systems I test on nor I did on the CI system. Regards, Jafar On Wed, Jan 6, 2021 at 6:41 AM Bruce & Breeanna Rennie <br...@dc...<mailto:br...@dc...>> wrote: Good evening Jafar, I hope this finds you well for the start of the New Year. I don't know if this is related to my system alone but I have found the following problem with running the make for the latest unicon download. When it gets to the gdbm directory, a couple of files are copied to the rt directory. If you rerun the make, there is a failure with a copy of the gdbm.h file as the destination is now read-only. I have fixed this on my system by running chmod against all files under rt. This appears to fix the problem. regards and blessing to you and your family Bruce Rennie |
From: Jafar Al-G. <to....@gm...> - 2021-01-07 19:55:35
|
Hi Bruce, Did this happen with source code checked out of GitHub git repo ? Or from prepackaged sources ? In either case, I don't know what would cause this as none of these files are marked as read-only AFAIK. I haven't seen this error on any of the systems I test on nor I did on the CI system. Regards, Jafar On Wed, Jan 6, 2021 at 6:41 AM Bruce & Breeanna Rennie <br...@dc...> wrote: > Good evening Jafar, > > I hope this finds you well for the start of the New Year. > > I don't know if this is related to my system alone but I have found the > following problem with running the make for the latest unicon download. > When it gets to the gdbm directory, a couple of files are copied to the > rt directory. If you rerun the make, there is a failure with a copy of > the gdbm.h file as the destination is now read-only. I have fixed this > on my system by running chmod against all files under rt. This appears > to fix the problem. > > regards and blessing to you and your family > > Bruce Rennie > |
From: Bruce & B. R. <br...@dc...> - 2021-01-06 12:41:52
|
Good evening Jafar, I hope this finds you well for the start of the New Year. I don't know if this is related to my system alone but I have found the following problem with running the make for the latest unicon download. When it gets to the gdbm directory, a couple of files are copied to the rt directory. If you rerun the make, there is a failure with a copy of the gdbm.h file as the destination is now read-only. I have fixed this on my system by running chmod against all files under rt. This appears to fix the problem. regards and blessing to you and your family Bruce Rennie |
From: Bruce & B. R. <br...@dc...> - 2020-12-28 00:40:03
|
Good morning to all, I hope this finds you and your families well. In looking at the semantics of specific Unicon operations, I have come across the following runtime error message that is needing correction Run-time error 122 File test035.icn; Line 5 set or table expected offending value: 1 Traceback: main() mutex(1,&null) from line 5 in test035.icn The "set or table expected" should be referring to all structures including lists and records. Again, this can wait till the new year for investigation. regards and blessings to you and your families Bruce Rennie |
From: Bruce & B. R. <br...@dc...> - 2020-12-26 08:02:48
|
Good afternoon Clinton, Thanks for the background. I think that the locals and the problems with [] in the class parameter declaration is going to either be insightfully fixed or both removed. At the moment, I am just trying to resolve the parser package and the placing of the normal unicon unigram.y file in the parser package. This is progressing well, so far and once I get it fixed, including adding the symbol table code that I developed some time ago, I'll submit to both you and Jafar for review to see what unexpected consequences might be in the changes that I have made. As far as initialisers are concerned, I think that they would be quite useful and I think that it is a potentially expressive way to handle the passing of parameters to bith methods and procedures in a far more universally consistent and polymorphic way. But that is for some more work further down the track. Just to give you a heads up. I am looking at merging my xoptions changes into the main unicon compiler as a seperate branch in the near future, probably January/February. When I do,m I would really apreciate both you and Jafar to have a close look to see if it has any merit for cleaning up the unicon compiler itself. I have a longer term intention to try and document the Unicon compiler as an example of how to do this oft undne task. Having had to maintain various systems over the years, it has been a bugbear to deal with codebases that had no documentation. The current unicon compiler has much more documetation than many of teh business production systems that I have had to deal with in the past. Far too many programmers in the business wordl do not have any interest at all in providing any kind of documentation for those who will follow them, At any, I;ll stop my ranting on this specific subject and let you get back to your family. regards and blessings Bruce Rennie On 26/12/20 4:24 pm, Jeffery, Clinton wrote: > Hi Bruce, > > Merry 2nd day of Christmas. Thank you for the bug report. I don't > remember exactly when or who added "local" declarations in classes, or > whether they are an accepted part of the Unicon language as documented > in the Unicon book. I do not see them in a quick scan of chapter 10. > Are they somewhere else in the Unicon book? Ideally, we would consult > the person who added this feature regarding a fix for this bug. > > Correct fixes for this bug report might be one of the following > alternatives: (1) remove the feature and make local declarations in > classes a syntax error; (2) make initializers illegal in class locals; > or (3) add initializer code from "class locals" to the > test1_initially() or to the test1() constructor procedure prior to the > initially method being called. > > Adding class local syntax poses a bit of a scope puzzle, since > initializers are out there at the class level and it is sort of a good > question when and in whose scope they will execute and any symbols > used in the initializers will be interpreted. I guess they are outside > the initially and should not have access to any declared initially > parameters or variables. But the whole purpose of the initially > section is to do the sort of thing initializers in class locals are > doing. Maybe that means class local initializers should be added to > the generated code in the test1() constructor procedure before the > initially() is called. To sum up, class "local" is revealed by > your test to be unfinished business. If it is in the Unicon book, the > bug should be fixed. If it is not in the Unicon book, the feature may > well be removed or changed before being accepted, and hopefully it > would be "finished" before it was accepted. Personally I do not like > the word "local" used in that context, local means something else to > me. "attribute" or "field" or "instance" would be a better word for > such class variables, but making one of them a reserved word would > break some programs. Maybe there is another word out there that would > be better. > > Cheers, > Clint > > On Fri, Dec 25, 2020 at 8:44 PM Bruce & Breeanna Rennie > <br...@dc... <mailto:br...@dc...>> wrote: > > Good afternoon Clinton and Jafar, > > I hope this find you and your families well at this time. > > This is another problem that can wait for the new year. Though I will > record the problem now for later investigation. > > If we enter the following unicon file > > class test1(a,b,c) > local d :=1, e:= [1,2,3], f > method m1(a1) > end > global x,y > record h1(h11,h12) > abstract method m2(a2) > initially(ax) > end > > > the file will compile but the incorrect code is generated as per > > Parsing test034.icn: . > /home/bruce/unicon/bin/icont -c -E -O test034.icn /tmp/uni54104263 > test034.icn: > No errors > #line 0 "/tmp/uni54104263" > #line 0 "test034.icn" > > > procedure test1_m1(self,a1) > > end > > procedure test1_m2(self,a2) > runerr(700, "method m2()") > > end > > > #line 7 "test034.icn" > procedure test1_initially(self,ax) > > return > end > # > # globals declared within the class > # > > #line 4 "test034.icn" > global x,y > record h1(h11,h12) > #line 1 "__faux.icn" > record test1__state(__s,__m,a,b,c,d,e,f) > record test1__methods(m1,m2,initially) > global test1__oprec > procedure test1(ax) > local self,clone > initial { > if /test1__oprec then test1initialize() > } > self := test1__state(&null,test1__oprec) > self.__s := self > self.__m.initially(self,ax) | fail > return self > end > > procedure test1initialize() > initial test1__oprec := > test1__methods(test1_m1,test1_m2,test1_initially) > end > > The problem is that the local class variables "d" and "e" are not > intialised anywhere. > > This has arisen out of the work I am doing at the moment for unifying > the Unicon parser and the parser package to the same unigram.y file. > > regards and blessing to you and your families > > Bruce Rennie > > > > _______________________________________________ > Unicon-ldif mailing list > Uni...@li... > https://lists.sourceforge.net/lists/listinfo/unicon-ldif |
From: Jeffery, C. <cli...@nm...> - 2020-12-26 07:17:11
|
Hi Bruce, Merry 2nd day of Christmas. Thank you for the bug report. I don't remember exactly when or who added "local" declarations in classes, or whether they are an accepted part of the Unicon language as documented in the Unicon book. I do not see them in a quick scan of chapter 10. Are they somewhere else in the Unicon book? Ideally, we would consult the person who added this feature regarding a fix for this bug. Correct fixes for this bug report might be one of the following alternatives: (1) remove the feature and make local declarations in classes a syntax error; (2) make initializers illegal in class locals; or (3) add initializer code from "class locals" to the test1_initially() or to the test1() constructor procedure prior to the initially method being called. Adding class local syntax poses a bit of a scope puzzle, since initializers are out there at the class level and it is sort of a good question when and in whose scope they will execute and any symbols used in the initializers will be interpreted. I guess they are outside the initially and should not have access to any declared initially parameters or variables. But the whole purpose of the initially section is to do the sort of thing initializers in class locals are doing. Maybe that means class local initializers should be added to the generated code in the test1() constructor procedure before the initially() is called. To sum up, class "local" is revealed by your test to be unfinished business. If it is in the Unicon book, the bug should be fixed. If it is not in the Unicon book, the feature may well be removed or changed before being accepted, and hopefully it would be "finished" before it was accepted. Personally I do not like the word "local" used in that context, local means something else to me. "attribute" or "field" or "instance" would be a better word for such class variables, but making one of them a reserved word would break some programs. Maybe there is another word out there that would be better. Cheers, Clint On Fri, Dec 25, 2020 at 8:44 PM Bruce & Breeanna Rennie <br...@dc...> wrote: > Good afternoon Clinton and Jafar, > > I hope this find you and your families well at this time. > > This is another problem that can wait for the new year. Though I will > record the problem now for later investigation. > > If we enter the following unicon file > > class test1(a,b,c) > local d :=1, e:= [1,2,3], f > method m1(a1) > end > global x,y > record h1(h11,h12) > abstract method m2(a2) > initially(ax) > end > > > the file will compile but the incorrect code is generated as per > > Parsing test034.icn: . > /home/bruce/unicon/bin/icont -c -E -O test034.icn /tmp/uni54104263 > test034.icn: > No errors > #line 0 "/tmp/uni54104263" > #line 0 "test034.icn" > > > procedure test1_m1(self,a1) > > end > > procedure test1_m2(self,a2) > runerr(700, "method m2()") > > end > > > #line 7 "test034.icn" > procedure test1_initially(self,ax) > > return > end > # > # globals declared within the class > # > > #line 4 "test034.icn" > global x,y > record h1(h11,h12) > #line 1 "__faux.icn" > record test1__state(__s,__m,a,b,c,d,e,f) > record test1__methods(m1,m2,initially) > global test1__oprec > procedure test1(ax) > local self,clone > initial { > if /test1__oprec then test1initialize() > } > self := test1__state(&null,test1__oprec) > self.__s := self > self.__m.initially(self,ax) | fail > return self > end > > procedure test1initialize() > initial test1__oprec := > test1__methods(test1_m1,test1_m2,test1_initially) > end > > The problem is that the local class variables "d" and "e" are not > intialised anywhere. > > This has arisen out of the work I am doing at the moment for unifying > the Unicon parser and the parser package to the same unigram.y file. > > regards and blessing to you and your families > > Bruce Rennie > |
From: Bruce & B. R. <br...@dc...> - 2020-12-26 03:45:15
|
Good afternoon Clinton and Jafar, I hope this find you and your families well at this time. This is another problem that can wait for the new year. Though I will record the problem now for later investigation. If we enter the following unicon file class test1(a,b,c) local d :=1, e:= [1,2,3], f method m1(a1) end global x,y record h1(h11,h12) abstract method m2(a2) initially(ax) end the file will compile but the incorrect code is generated as per Parsing test034.icn: . /home/bruce/unicon/bin/icont -c -E -O test034.icn /tmp/uni54104263 test034.icn: No errors #line 0 "/tmp/uni54104263" #line 0 "test034.icn" procedure test1_m1(self,a1) end procedure test1_m2(self,a2) runerr(700, "method m2()") end #line 7 "test034.icn" procedure test1_initially(self,ax) return end # # globals declared within the class # #line 4 "test034.icn" global x,y record h1(h11,h12) #line 1 "__faux.icn" record test1__state(__s,__m,a,b,c,d,e,f) record test1__methods(m1,m2,initially) global test1__oprec procedure test1(ax) local self,clone initial { if /test1__oprec then test1initialize() } self := test1__state(&null,test1__oprec) self.__s := self self.__m.initially(self,ax) | fail return self end procedure test1initialize() initial test1__oprec := test1__methods(test1_m1,test1_m2,test1_initially) end The problem is that the local class variables "d" and "e" are not intialised anywhere. This has arisen out of the work I am doing at the moment for unifying the Unicon parser and the parser package to the same unigram.y file. regards and blessing to you and your families Bruce Rennie |
From: Bruce & B. R. <br...@dc...> - 2020-12-23 01:21:45
|
Good afternoon Clinton and Jafar, I hope you and your families are keeping well in your northern winter. This will keep until after the new year. I have found an interesting error arising when using the following productions from the current unicon grammar carglist: { $$ := argList( , , &null) } ; | cparmlist { $$ := argList( , , $1) } ; | cparmlist LBRACK RBRACK { $$ := argList("[]" , , $1) } ; There is no errors when you use the following in the same file: test032.icn class test1(a, b, c[]) end class test2:test1(d,e) end However, if I create another file: test033.icn that references either of these classes as in class test3:test2(x,y,z) end we find that the following error arises when compiling the second file: test033.icn unicon -c test033 Parsing test033.icn: . inherits test2 from test032.icn inherits test1 from test032.icn /home/bruce/unicon/bin/icont -c -O test033.icn /tmp/uni14806497 Translating: test033.icn: __faux.icn:2: # "c": syntax error (249;368) test3 test3initialize 1 error The output from "unicon -E test032 &>test032.output" gives Parsing test032.icn: .. /home/bruce/unicon/bin/icont -c -E -O test032.icn /tmp/uni43246292 test032.icn: No errors #line 0 "/tmp/uni43246292" #line 0 "test032.icn" #line 1 "__faux.icn" record test1__state(__s,__m,a,b,c) record test1__methods() global test1__oprec procedure test1(a,b,c[]) local self,clone initial { if /test1__oprec then test1initialize() } self := test1__state(&null,test1__oprec,a,b,c) self.__s := self return self end procedure test1initialize() initial test1__oprec := test1__methods() end #line 1 "__faux.icn" record test2__state(__s,__m,d,e,a,b,c) record test2__methods(test1) global test2__oprec, test1__oprec procedure test2(d,e,a,b,c) local self,clone initial { if /test2__oprec then test2initialize() if /test1__oprec then test1initialize() test2__oprec.test1 := test1__oprec } self := test2__state(&null,test2__oprec,d,e,a,b,c) self.__s := self return self end procedure test2initialize() initial test2__oprec := test2__methods() end while the output from "unicon -E test033 &>test033.output" gives Parsing test033.icn: . inherits test2 from test032.icn inherits test1 from test032.icn /home/bruce/unicon/bin/icont -c -E -O test033.icn /tmp/uni75782225 test033.icn: No errors #line 0 "/tmp/uni75782225" #line 0 "test033.icn" link "/home/bruce/unicon/local/test032" link "/home/bruce/unicon/local/test032" #line 1 "__faux.icn" record test3__state(__s,__m,x,y,z,d,e,a,b,c[]) record test3__methods(test2,test1) global test3__oprec, test2__oprec, test1__oprec procedure test3(x,y,z,d,e,a,b,c[]) local self,clone initial { if /test3__oprec then test3initialize() if /test2__oprec then test2initialize() test3__oprec.test2 := test2__oprec if /test1__oprec then test1initialize() test3__oprec.test1 := test1__oprec } self := test3__state(&null,test3__oprec,x,y,z,d,e,a,b,c[]) self.__s := self return self end procedure test3initialize() initial test3__oprec := test3__methods() end Looking at the code being generated, it appears that state records in the second file are being specified incorrectly and in the first file, the procedure definition for test2 is being specified incorrectly. I suspect that for test2 the line should read procedure test2(d,e,a,b,c[]) and for both references to "test3__state" should be record test3__state(__s,__m,x,y,z,d,e,a,b,c) and self := test3__state(&null,test3__oprec,x,y,z,d,e,a,b,c) What do you gentlemen think? Like I say it can wait until after the new year. regards and blessing of the Almighty on both you and your families Bruce Rennie |
From: Bruce & B. R. <br...@dc...> - 2020-10-31 12:17:30
|
Good evening Clinton and Jafar, This is just a heads up that I may have found a logic error in the Unicon compiler's handling of names in packages when specifying link directives to non-package files. A quick summary. I am making a number of updates to the uni/lib files. For testing purposes, I have linked in ximage.icn into a couple of these files and procedures defined in the package in an external file are coming up as containing &null values. When I prefix the procedure name with the package name as in lang:: I no longer get any errors. I will endeavour to collect further information in the next week and try to narrow it down to where the problem is. Blessings upon both of and your families. Bruce Rennie |
From: Bruce & B. R. <br...@dc...> - 2020-10-27 23:26:05
|
Good morning Clinton, On 28/10/20 9:14 am, Jeffery, Clinton wrote: > Hi Bruce, > > A memory violation is usually a bug, so Thank You for the bug report! > I don't recall who wrote methodnames(). Maybe I should be polite in my > assessment of it. Minimally, its author did not check whether the > record value given was actually a class instance, as you note. > Calling methodnames(r) for a non-class record instance r should > probably result in a new runtime error instead of memory violation. > > Your other comment, that there should be only one parameter, raises > another can of worms. In the C code for methodnames() there is an > undocumented second parameter that is a flag. I think it modifies the > format of the output names. Frightfully, the code assumes said second > parameter will be passed as an integer. In the Unicon runtime system > we are not allowed to assume anything like that, we have to check > first before we use a parameter's value. The fact that it is > undocumented suggests that I was not 100% on board with the second > parameter as implemented. Besides the untested and buggy > implementation, the design is sketchy. > Thank you. Thank you. Thank you. I needed the humour of your response on this cold and somewhat autumnish spring day. Again thank you. regards Bruce Rennie > Clint > > On Tue, Oct 27, 2020 at 3:50 PM Bruce & Breeanna Rennie > <br...@dc... <mailto:br...@dc...>> wrote: > > Good morning Clinton and Jafar, > > In doing some testing of the langprocs.icn procedures, I have come > across an error that may be incorrect. > > I have a record declaration as follows > > record arecord(n,x) > > I run the following code > > r := arecord(1,2) > > every write("methodname:", !methodnames(r) | "methodnames fails") > > and the following runtime error is the result > > Run-time error 302 > File test027.icn; Line 52 > memory violation > Traceback: > main() > methodnames(record arecord_1,&null) from line 52 in test027.icn > > > My question for you gentlemen is should this be the error returned > and > not the one related to it not being an object? Or should it just > fail, > since the membernames(r) actually returns a list of fields? > > The other point is that the runtime message is indicating a second > parameter when there should only be 1. > > regards > > Bruce Rennie > |
From: Jeffery, C. <cli...@nm...> - 2020-10-27 23:15:14
|
Hi Bruce, A memory violation is usually a bug, so Thank You for the bug report! I don't recall who wrote methodnames(). Maybe I should be polite in my assessment of it. Minimally, its author did not check whether the record value given was actually a class instance, as you note. Calling methodnames(r) for a non-class record instance r should probably result in a new runtime error instead of memory violation. Your other comment, that there should be only one parameter, raises another can of worms. In the C code for methodnames() there is an undocumented second parameter that is a flag. I think it modifies the format of the output names. Frightfully, the code assumes said second parameter will be passed as an integer. In the Unicon runtime system we are not allowed to assume anything like that, we have to check first before we use a parameter's value. The fact that it is undocumented suggests that I was not 100% on board with the second parameter as implemented. Besides the untested and buggy implementation, the design is sketchy. Clint On Tue, Oct 27, 2020 at 3:50 PM Bruce & Breeanna Rennie <br...@dc...> wrote: > Good morning Clinton and Jafar, > > In doing some testing of the langprocs.icn procedures, I have come > across an error that may be incorrect. > > I have a record declaration as follows > > record arecord(n,x) > > I run the following code > > r := arecord(1,2) > > every write("methodname:", !methodnames(r) | "methodnames fails") > > and the following runtime error is the result > > Run-time error 302 > File test027.icn; Line 52 > memory violation > Traceback: > main() > methodnames(record arecord_1,&null) from line 52 in test027.icn > > > My question for you gentlemen is should this be the error returned and > not the one related to it not being an object? Or should it just fail, > since the membernames(r) actually returns a list of fields? > > The other point is that the runtime message is indicating a second > parameter when there should only be 1. > > regards > > Bruce Rennie > |
From: Bruce & B. R. <br...@dc...> - 2020-10-27 21:50:52
|
Good morning Clinton and Jafar, In doing some testing of the langprocs.icn procedures, I have come across an error that may be incorrect. I have a record declaration as follows record arecord(n,x) I run the following code r := arecord(1,2) every write("methodname:", !methodnames(r) | "methodnames fails") and the following runtime error is the result Run-time error 302 File test027.icn; Line 52 memory violation Traceback: main() methodnames(record arecord_1,&null) from line 52 in test027.icn My question for you gentlemen is should this be the error returned and not the one related to it not being an object? Or should it just fail, since the membernames(r) actually returns a list of fields? The other point is that the runtime message is indicating a second parameter when there should only be 1. regards Bruce Rennie |
From: Bruce & B. R. <br...@dc...> - 2020-10-04 03:41:44
|
Good afternoon Clinton and Jafar, Here is an extended example of the problem. procedure main() local lst, lst2 lst := [1, 1, 1] lst2 := list(2,1) write("*lst:", *lst) write("lst:", ximage(lst)) write("*lst2:", *lst2) write("lst2:", ximage(lst2)) every write(!lst) every write(!lst2) lst |||:= lst2 write("*lst:", *lst) every i := 1 to *lst do { write("i:", i) write("lst[", i, "]:", lst[i]) } every write(!lst) write("lst:", ximage(lst)) end link ximage and the output obtained *lst:3 lst:L1 := list(3,1) *lst2:2 lst2:L2 := list(2) L2[1] := 1 L2[2] := 1 1 1 1 1 1 *lst:5 i:1 lst[1]:1 i:2 lst[2]:1 i:3 lst[3]:1 i:4 Run-time error 302 File test023.icn; Line 16 memory violation Traceback: main() The error appears to be in what has been created by the list(2,1) when it is concatenated to another list. regards Bruce Rennie. On 4/10/20 11:11 am, Bruce & Breeanna Rennie wrote: > Good afternoon Clinton and Jafar, > > the problem on the main discussion list by Peter Lane is easily > duplicated with the following code > > procedure main() > local lst, lst2 > > lst := [1, 1, 1] > lst2 := list(2,1) > write("*lst:", *lst) > write("lst:", ximage(lst)) > write("*lst2:", *lst2) > write("lst2:", ximage(lst2)) > lst |||:= lst2 > write("*lst:", *lst) > write("lst:", ximage(lst)) > > end > > link ximage > > > and the output obtained is: > > [bruce@Bruce local]$ test023 > *lst:3 > lst:L1 := list(3,1) > *lst2:2 > lst2:L2 := list(2) > L2[1] := 1 > L2[2] := 1 > *lst:5 > > Run-time error 302 > File ximage.icn; Line 102 > memory violation > Traceback: > main() > Segmentation fault (core dumped) > > > How do you want this reported? > > regards > > Bruce Rennie > > > _______________________________________________ > Unicon-ldif mailing list > Uni...@li... > https://lists.sourceforge.net/lists/listinfo/unicon-ldif |
From: Bruce & B. R. <br...@dc...> - 2020-10-04 01:20:03
|
Good afternoon Clinton and Jafar, the problem on the main discussion list by Peter Lane is easily duplicated with the following code procedure main() local lst, lst2 lst := [1, 1, 1] lst2 := list(2,1) write("*lst:", *lst) write("lst:", ximage(lst)) write("*lst2:", *lst2) write("lst2:", ximage(lst2)) lst |||:= lst2 write("*lst:", *lst) write("lst:", ximage(lst)) end link ximage and the output obtained is: [bruce@Bruce local]$ test023 *lst:3 lst:L1 := list(3,1) *lst2:2 lst2:L2 := list(2) L2[1] := 1 L2[2] := 1 *lst:5 Run-time error 302 File ximage.icn; Line 102 memory violation Traceback: main() Segmentation fault (core dumped) How do you want this reported? regards Bruce Rennie |
From: Bruce & B. R. <br...@dc...> - 2020-08-13 05:33:05
|
Good afternoon Clinton and Jafar, I hope this finds you well. In running the test suite for the github download, I am getting a failure when running pty_uni. The following message is generated Run-time error 302 File pty_uni.icn; Line 43 memory violation Traceback: main() flush(file(../../bin/udb)) from line 43 in pty_uni.icn When the flush() is commented out, the program runs to completion. Where would you like this to be noted, on sourceforge or girhub or both? There is another problem that relates to the pty_uni.std but that is just related to the actual responses that come back from udb. There is a build difference between what is expected in pty_uni.std ( UDB Version 2.0, December 1, 2009) and what is currently produced from udb (UDB Version 2.1, July 4, 2018). This I will fix and submit a pull request for when I complete going through the full test regime. regards Bruce Rennie |
From: Steve W. <sb...@ta...> - 2020-06-16 16:43:56
|
Okay - once I dug out from all the holes I threw myself into, I've gotten it to build with operator overloading. (Thanks Jafar!). For the record: - DON'T do: cd $UNICON find . -name \*.u | xargs rm - Instead do (as Jafar suggests): cd $UNICON make Pure the former removes ./uni/unicon/unigram.u and ./uni/unicon/idol.u, which SHOULDN'T be removed. I did a new git pull to restore them, then went through the "make Pure;configure --enable-ovld;make" cycle and everything built fine. Incidently, the Makefile in ./uni/unicon includes commented out commands for rebuilding both unigram.u and idol.u. But building idol.u requires a working unicon command which, of course, I didn't have. So uncommenting those lines didn't help me. On 6/16/20 7:43 AM, Steve Wampler wrote: > On 6/16/20 7:36 AM, Jafar Al-Gharaibeh wrote: >> Also, make sure your remove all of the .u files in your software >> > > I'm not even getting to my own files, things are dying in the make. > After: > > make Pure # no *.u files left after this > configure --enable-ovld > > the make command now fails even eariler in the process!: > >> cd unicon; make >> make[2]: Entering directory `/opt/unicon/uni/unicon' >> ../../bin/icont -s -c unicon >> make[2]: *** No rule to make target `unigram.u', needed by `unicon'. >> Stop. >> make[2]: Leaving directory `/opt/unicon/uni/unicon' >> make[1]: *** [unicon] Error 2 >> make[1]: Leaving directory `/opt/unicon/uni' >> make: *** [default] Error 2 >> [sbw@tapestry]/opt/unicon% > >> On Tue, Jun 16, 2020, 9:35 AM Jafar Al-Gharaibeh <to....@gm... >> <mailto:to....@gm...>> wrote: >> >> Do make Pure. If you still have .u files let me know please, we >> should fix those. >> >> On Tue, Jun 16, 2020, 9:33 AM Steve Wampler >> <sb...@ta... <mailto:sb...@ta...>> >> wrote: >> >> On 6/16/20 7:31 AM, Steve Wampler wrote: >> > Hi Jafar, >> > >> > On 6/16/20 7:24 AM, Jafar Al-Gharaibeh wrote: >> >> Have you tried to remove all .u files and then do a clean >> build ? >> > >> > I've done a "make clean", then a "configure --enable-olvd", >> followed >> > by a "make". >> > Is the "make clean" insufficient to remove all the *.u files? >> > >> >> Ah, apparently not. There were a lot of *.u left after the >> make clean. >> Let me explicitly remove those and try again... >> >> -- Steve Wampler - sb...@ta... >> <mailto:sb...@ta...> >> The gods that smiled at your birth are now laughing out loud - >> fortune cookie >> > > -- Steve Wampler - sb...@ta... The gods that smiled at your birth are now laughing out loud - fortune cookie |
From: Jafar Al-G. <to....@gm...> - 2020-06-16 16:41:02
|
There are a few (a couple?) files under unicon/uni/unicon that shouldn't be deleted. Do : git status and you will be able to see which are the files you need. I did this on my end and this is what I got: jafar@jtr:~/unicon/uni/unicon$ git status deleted: idol.u deleted: unigram.u To get those file, check them out from your local git repo: jafar@jtr:~/unicon/uni/unicon$ git checkout idol.u unigram.u After that, "git status" didn't give me any diff output. Reconfigure and rebuild and see if it works. --Jafar On Tue, Jun 16, 2020 at 9:43 AM Steve Wampler <sb...@ta...> wrote: > On 6/16/20 7:36 AM, Jafar Al-Gharaibeh wrote: > > Also, make sure your remove all of the .u files in your software > > > > I'm not even getting to my own files, things are dying in the make. After: > > make Pure # no *.u files left after this > configure --enable-ovld > > the make command now fails even eariler in the process!: > > > cd unicon; make > > make[2]: Entering directory `/opt/unicon/uni/unicon' > > ../../bin/icont -s -c unicon > > make[2]: *** No rule to make target `unigram.u', needed by `unicon'. > > Stop. > > make[2]: Leaving directory `/opt/unicon/uni/unicon' > > make[1]: *** [unicon] Error 2 > > make[1]: Leaving directory `/opt/unicon/uni' > > make: *** [default] Error 2 > > [sbw@tapestry]/opt/unicon% > > > On Tue, Jun 16, 2020, 9:35 AM Jafar Al-Gharaibeh <to....@gm... > > <mailto:to....@gm...>> wrote: > > > > Do make Pure. If you still have .u files let me know please, we > > should fix those. > > > > On Tue, Jun 16, 2020, 9:33 AM Steve Wampler > > <sb...@ta... <mailto:sb...@ta...>> > wrote: > > > > On 6/16/20 7:31 AM, Steve Wampler wrote: > > > Hi Jafar, > > > > > > On 6/16/20 7:24 AM, Jafar Al-Gharaibeh wrote: > > >> Have you tried to remove all .u files and then do a clean > > build ? > > > > > > I've done a "make clean", then a "configure --enable-olvd", > > followed > > > by a "make". > > > Is the "make clean" insufficient to remove all the *.u files? > > > > > > > Ah, apparently not. There were a lot of *.u left after the > > make clean. > > Let me explicitly remove those and try again... > > > > -- > > Steve Wampler - sb...@ta... > > <mailto:sb...@ta...> > > The gods that smiled at your birth are now laughing out loud - > > fortune cookie > > > > > -- > Steve Wampler - sb...@ta... > The gods that smiled at your birth are now laughing out loud - fortune > cookie > > |