Re: [Factor-talk] gcc versions
Interesting. Both versions work with my clang.
ergmac:factor erg$ [master*] clang --version
Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn)
Target: x86_64-apple-darwin14.4.0
Thread model: posix
So if the fix is correct, then we are all good.
Doug
On Fri, Aug 14, 2015 at 10:51 AM, Jon Harper jon.harpe...@gmail.com wrote:
Well that's GCC 4.7.2 https://gcc.gnu.org/gcc-4.7/ September 20, 2012
Gcc did fix this in GCC 4.7.3 https://gcc.gnu.org/gcc-4.7/ April 11,
2013
Also, clang does not error on the implicit this, but crashes hard earlier
than gcc :)
$ clang --version
Debian clang version 3.0-6.2 (tags/RELEASE_30/final) (based on LLVM 3.0)
Target: i386-pc-linux-gnu
Thread model: posix
$ CC=clang CXX=clang++ make
make `./build-support/factor.sh make-target`
[...snip...]
1. vm/free_list_allocator.hpp:124:57: current parser token ';'
2. vm/free_list_allocator.hpp:1:1: parsing namespace 'factor'
3. vm/free_list_allocator.hpp:123:68: parsing function body 'sweep'
4. vm/free_list_allocator.hpp:123:68: in compound statement ('{}')
clang: error: unable to execute command: Segmentation fault
https://lists.sourceforge.net/lists/listinfo/factor-talk
--
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
--
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Why does numberstring append .0 on my German system ?
For info, it works directly on x86 linux
Jon
On Fri, Aug 14, 2015 at 6:17 AM, Georg Simon georg.si...@auge.de wrote:
For me the need lies in the future.
I am using a Factor written todo list editor, primarily to learn to use
the Factor UI.
I now add deadlines. So I want to display numbers in a Factor table.
It would have been proper to display them locale dependant, but it is
not necessary for now.
Am Fri, 14 Aug 2015 00:01:20 +0200
schrieb Jon Harper jon.harpe...@gmail.com:
So I looked into this, trying to solve it by calling printf through
the FFI with a locale setup and cleanup.
The difficulty comes from the fact that printf is a variadic
function.. Factor's ffi doesn't support them, at least no in a cross
platform manner, right?
So a workaround could be to wrap printf in C many times, compile that
to a shared library and call the different wrappers with the FFI
depending on the number of arguments and their types, but it would be
nicer to have a better support of variadic functions.
Anyway, it (kind of) worked on linux x86_64 with the following code:
http://paste.factorcode.org/paste?id=3584
Since printf is a variadic function, you have to use FUNCTION-ALIAS to
create functions with the correct number of arguments and the correct
types. So for example,
FUNCTION-ALIAS: mysnprintf-int2 int snprintf ( char* result, size_t
size, c-string format, int d, int d2 )
would work too.
However, passing floats didn't work on linux x86_64, because the
system V AMD64 ABI says that the number of float arguments must be in
RAX before calling the function, and factor always sets this to 0.
With the following diff, it worked for 1 float:
in cpu/x86/64/64.factor (and basis/cpu/x86/64/64.factor ??)
-M: x86.64 %prepare-var-args ( -- ) RAX RAX XOR ;
+M: x86.64 %prepare-var-args ( -- ) RAX 1 MOV ;
I don't know how hard it would be to generate the correct value for
RAX for variable arguments.
Also, I'm not sure if it works better for other ABI/platforms.
Do you think that's something worth investigating ?
Jon
On Wed, Aug 12, 2015 at 7:10 AM, Georg Simon georg.si...@auge.de
wrote:
Am Tue, 11 Aug 2015 09:02:33 -0700
schrieb John Benediktsson mrj...@gmail.com:
Thank you. So I didn't overlook existing locales support.
Properly supporting locales, even in a small way, would be a good
thing to add.
Factor is currently locale-independent, partly because of a
desire for homoiconicity, and partly because it prevents things
like tests that break depending on the system locale[1].
We have discussed adding a locale vocabulary or a with-locale
combinator that can influence presentation of numbers and strings,
maybe looking at how other languages work[2]. Probably we'd want
to keep the math.parser locale independent, but provide ways for
things like present / printf to be locale-aware.
If this is an issue for something you are building, you could use
alien.ffi to call sprintf or use C++ stringstream or something and
call the library from Factor, or do something slow like this,
calling out to Python:
: format-with-locale ( n locale -- s )
swap [
python , -c ,
import locale; locale.setlocale(locale.LC_ALL, \%s\);
print(locale.format(\%%f\, %s)) sprintf ,
] { } make B utf8 [ readln ] with-process-reader ;
IN: scratchpad 1.5 fr_FR format-with-locale .
1,50
---
[1] https://github.com/slavapestov/factor/issues/905
[2] https://docs.python.org/3/library/locale.html
--
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
--
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
--
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Why does numberstring append .0 on my German system ?
Maybe just format them locally so you see something you expect?
. , replace
On Thu, Aug 13, 2015 at 9:17 PM, Georg Simon georg.si...@auge.de wrote:
For me the need lies in the future.
I am using a Factor written todo list editor, primarily to learn to use
the Factor UI.
I now add deadlines. So I want to display numbers in a Factor table.
It would have been proper to display them locale dependant, but it is
not necessary for now.
Am Fri, 14 Aug 2015 00:01:20 +0200
schrieb Jon Harper jon.harpe...@gmail.com:
So I looked into this, trying to solve it by calling printf through
the FFI with a locale setup and cleanup.
The difficulty comes from the fact that printf is a variadic
function.. Factor's ffi doesn't support them, at least no in a cross
platform manner, right?
So a workaround could be to wrap printf in C many times, compile that
to a shared library and call the different wrappers with the FFI
depending on the number of arguments and their types, but it would be
nicer to have a better support of variadic functions.
Anyway, it (kind of) worked on linux x86_64 with the following code:
http://paste.factorcode.org/paste?id=3584
Since printf is a variadic function, you have to use FUNCTION-ALIAS to
create functions with the correct number of arguments and the correct
types. So for example,
FUNCTION-ALIAS: mysnprintf-int2 int snprintf ( char* result, size_t
size, c-string format, int d, int d2 )
would work too.
However, passing floats didn't work on linux x86_64, because the
system V AMD64 ABI says that the number of float arguments must be in
RAX before calling the function, and factor always sets this to 0.
With the following diff, it worked for 1 float:
in cpu/x86/64/64.factor (and basis/cpu/x86/64/64.factor ??)
-M: x86.64 %prepare-var-args ( -- ) RAX RAX XOR ;
+M: x86.64 %prepare-var-args ( -- ) RAX 1 MOV ;
I don't know how hard it would be to generate the correct value for
RAX for variable arguments.
Also, I'm not sure if it works better for other ABI/platforms.
Do you think that's something worth investigating ?
Jon
On Wed, Aug 12, 2015 at 7:10 AM, Georg Simon georg.si...@auge.de
wrote:
Am Tue, 11 Aug 2015 09:02:33 -0700
schrieb John Benediktsson mrj...@gmail.com:
Thank you. So I didn't overlook existing locales support.
Properly supporting locales, even in a small way, would be a good
thing to add.
Factor is currently locale-independent, partly because of a
desire for homoiconicity, and partly because it prevents things
like tests that break depending on the system locale[1].
We have discussed adding a locale vocabulary or a with-locale
combinator that can influence presentation of numbers and strings,
maybe looking at how other languages work[2]. Probably we'd want
to keep the math.parser locale independent, but provide ways for
things like present / printf to be locale-aware.
If this is an issue for something you are building, you could use
alien.ffi to call sprintf or use C++ stringstream or something and
call the library from Factor, or do something slow like this,
calling out to Python:
: format-with-locale ( n locale -- s )
swap [
python , -c ,
import locale; locale.setlocale(locale.LC_ALL, \%s\);
print(locale.format(\%%f\, %s)) sprintf ,
] { } make B utf8 [ readln ] with-process-reader ;
IN: scratchpad 1.5 fr_FR format-with-locale .
1,50
---
[1] https://github.com/slavapestov/factor/issues/905
[2] https://docs.python.org/3/library/locale.html
--
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
--
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
--
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
[Factor-talk] gcc versions
Hi, for info, we can't compile the factor vm with the default compiler (gcc 4.7.2) of debian oldstable wheezy anymore. First, it has a false compilation error ( https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54277): g++ -c -x c++-header -Wall -DFACTOR_VERSION=0.98 -DFACTOR_GIT_LABEL=heads/master-5ba44b37bc82bfdea706c16f33b3bbc13b9ca87c -fomit-frame-pointer -Wl,--no-as-needed -m32 -O3 -g -std=c++11 -o vm/master.hpp.gch vm/master.hpp In file included from vm/master.hpp:112:0: vm/free_list_allocator.hpp: In lambda function: vm/free_list_allocator.hpp:137:35: error: no matching function for call to ‘factor::mark_bits::marked_p(factor::cell) const’ vm/free_list_allocator.hpp:137:35: note: candidate is: In file included from vm/master.hpp:109:0: vm/mark_bits.hpp:81:8: note: bool factor::mark_bits::marked_p(factor::cell) near match vm/mark_bits.hpp:81:8: note: no known conversion for implicit ‘this’ parameter from ‘const factor::mark_bits*’ to ‘factor::mark_bits*’ The following patch workarounds error: diff --git a/vm/free_list_allocator.hpp b/vm/free_list_allocator.hpp index 65e6851..461004c 100644 --- a/vm/free_list_allocator.hpp +++ b/vm/free_list_allocator.hpp @@ -137 +137 @@ void free_list_allocatorBlock::compact(Iterator iter, Fixup fixup, -if (!state.marked_p(block_addr)) +if (!this-state.marked_p(block_addr)) Even with the workaround, when then have g++ -c -Wall -DFACTOR_VERSION=0.98 -DFACTOR_GIT_LABEL=heads/master-5ba44b37bc82bfdea706c16f33b3bbc13b9ca87c -fomit-frame-pointer -Wl,--no-as-needed -m32 -O3 -g -std=c++11 -o vm/compaction.o vm/compaction.cpp vm/compaction.cpp: In lambda function: vm/compaction.cpp:165:1: internal compiler error: in get_expr_operands, at tree-ssa-operands.c:1035 Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-4.7/README.Bugs for instructions. Jon -- ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Why does numberstring append .0 on my German system ?
By the way, I do not think it is a good idea to directly parse or
format numbers based on locale, for portability.
I would rather have different functions that also take a locale into
account (not necessarily the system one) and a constant with the
system locale
2015-08-14 18:52 GMT+02:00 Jon Harper jon.harpe...@gmail.com:
For info, it works directly on x86 linux
Jon
On Fri, Aug 14, 2015 at 6:17 AM, Georg Simon georg.si...@auge.de wrote:
For me the need lies in the future.
I am using a Factor written todo list editor, primarily to learn to use
the Factor UI.
I now add deadlines. So I want to display numbers in a Factor table.
It would have been proper to display them locale dependant, but it is
not necessary for now.
Am Fri, 14 Aug 2015 00:01:20 +0200
schrieb Jon Harper jon.harpe...@gmail.com:
So I looked into this, trying to solve it by calling printf through
the FFI with a locale setup and cleanup.
The difficulty comes from the fact that printf is a variadic
function.. Factor's ffi doesn't support them, at least no in a cross
platform manner, right?
So a workaround could be to wrap printf in C many times, compile that
to a shared library and call the different wrappers with the FFI
depending on the number of arguments and their types, but it would be
nicer to have a better support of variadic functions.
Anyway, it (kind of) worked on linux x86_64 with the following code:
http://paste.factorcode.org/paste?id=3584
Since printf is a variadic function, you have to use FUNCTION-ALIAS to
create functions with the correct number of arguments and the correct
types. So for example,
FUNCTION-ALIAS: mysnprintf-int2 int snprintf ( char* result, size_t
size, c-string format, int d, int d2 )
would work too.
However, passing floats didn't work on linux x86_64, because the
system V AMD64 ABI says that the number of float arguments must be in
RAX before calling the function, and factor always sets this to 0.
With the following diff, it worked for 1 float:
in cpu/x86/64/64.factor (and basis/cpu/x86/64/64.factor ??)
-M: x86.64 %prepare-var-args ( -- ) RAX RAX XOR ;
+M: x86.64 %prepare-var-args ( -- ) RAX 1 MOV ;
I don't know how hard it would be to generate the correct value for
RAX for variable arguments.
Also, I'm not sure if it works better for other ABI/platforms.
Do you think that's something worth investigating ?
Jon
On Wed, Aug 12, 2015 at 7:10 AM, Georg Simon georg.si...@auge.de
wrote:
Am Tue, 11 Aug 2015 09:02:33 -0700
schrieb John Benediktsson mrj...@gmail.com:
Thank you. So I didn't overlook existing locales support.
Properly supporting locales, even in a small way, would be a good
thing to add.
Factor is currently locale-independent, partly because of a
desire for homoiconicity, and partly because it prevents things
like tests that break depending on the system locale[1].
We have discussed adding a locale vocabulary or a with-locale
combinator that can influence presentation of numbers and strings,
maybe looking at how other languages work[2]. Probably we'd want
to keep the math.parser locale independent, but provide ways for
things like present / printf to be locale-aware.
If this is an issue for something you are building, you could use
alien.ffi to call sprintf or use C++ stringstream or something and
call the library from Factor, or do something slow like this,
calling out to Python:
: format-with-locale ( n locale -- s )
swap [
python , -c ,
import locale; locale.setlocale(locale.LC_ALL, \%s\);
print(locale.format(\%%f\, %s)) sprintf ,
] { } make B utf8 [ readln ] with-process-reader ;
IN: scratchpad 1.5 fr_FR format-with-locale .
1,50
---
[1] https://github.com/slavapestov/factor/issues/905
[2] https://docs.python.org/3/library/locale.html
--
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
--
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
--
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
--
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] gcc versions
Maybe gcc should spend more time implementing C++14 and fixing bugs and less time worrying about someone stealing their AST. You can use clang and it should work. CC=clang CXX=clang++ make I'll patch the implicit this but I don't know what else to say. :) Doug On Fri, Aug 14, 2015 at 10:00 AM, Jon Harper jon.harpe...@gmail.com wrote: Hi, for info, we can't compile the factor vm with the default compiler (gcc 4.7.2) of debian oldstable wheezy anymore. First, it has a false compilation error ( https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54277): g++ -c -x c++-header -Wall -DFACTOR_VERSION=0.98 -DFACTOR_GIT_LABEL=heads/master-5ba44b37bc82bfdea706c16f33b3bbc13b9ca87c -fomit-frame-pointer -Wl,--no-as-needed -m32 -O3 -g -std=c++11 -o vm/master.hpp.gch vm/master.hpp In file included from vm/master.hpp:112:0: vm/free_list_allocator.hpp: In lambda function: vm/free_list_allocator.hpp:137:35: error: no matching function for call to ‘factor::mark_bits::marked_p(factor::cell) const’ vm/free_list_allocator.hpp:137:35: note: candidate is: In file included from vm/master.hpp:109:0: vm/mark_bits.hpp:81:8: note: bool factor::mark_bits::marked_p(factor::cell) near match vm/mark_bits.hpp:81:8: note: no known conversion for implicit ‘this’ parameter from ‘const factor::mark_bits*’ to ‘factor::mark_bits*’ The following patch workarounds error: diff --git a/vm/free_list_allocator.hpp b/vm/free_list_allocator.hpp index 65e6851..461004c 100644 --- a/vm/free_list_allocator.hpp +++ b/vm/free_list_allocator.hpp @@ -137 +137 @@ void free_list_allocatorBlock::compact(Iterator iter, Fixup fixup, -if (!state.marked_p(block_addr)) +if (!this-state.marked_p(block_addr)) Even with the workaround, when then have g++ -c -Wall -DFACTOR_VERSION=0.98 -DFACTOR_GIT_LABEL=heads/master-5ba44b37bc82bfdea706c16f33b3bbc13b9ca87c -fomit-frame-pointer -Wl,--no-as-needed -m32 -O3 -g -std=c++11 -o vm/compaction.o vm/compaction.cpp vm/compaction.cpp: In lambda function: vm/compaction.cpp:165:1: internal compiler error: in get_expr_operands, at tree-ssa-operands.c:1035 Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-4.7/README.Bugs for instructions. Jon -- ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk -- ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] gcc versions
So if the fix is correct, then we are all good.
The implicit this fix doesn't change anything:
With Wheezy's clang, it has no effect: it always segfaults during the
precompilation of master.hpp
With Wheezy's gcc, it goes from a false negative error during the
precompilation of master.hpp to a segfault during the compilation of
compaction.cpp
Also, there are tons of other implicit this uses. This one just happens to
be in a lambda and calling a non const method of this.
I'm not sure we want to support 2012's compilers ?
Jon
On Fri, Aug 14, 2015 at 7:54 PM, Doug Coleman doug.cole...@gmail.com
wrote:
Interesting. Both versions work with my clang.
ergmac:factor erg$ [master*] clang --version
Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn)
Target: x86_64-apple-darwin14.4.0
Thread model: posix
So if the fix is correct, then we are all good.
Doug
On Fri, Aug 14, 2015 at 10:51 AM, Jon Harper jon.harpe...@gmail.com
wrote:
Well that's GCC 4.7.2 https://gcc.gnu.org/gcc-4.7/ September 20, 2012
Gcc did fix this in GCC 4.7.3 https://gcc.gnu.org/gcc-4.7/ April 11,
2013
Also, clang does not error on the implicit this, but crashes hard earlier
than gcc :)
$ clang --version
Debian clang version 3.0-6.2 (tags/RELEASE_30/final) (based on LLVM 3.0)
Target: i386-pc-linux-gnu
Thread model: posix
$ CC=clang CXX=clang++ make
make `./build-support/factor.sh make-target`
[...snip...]
1. vm/free_list_allocator.hpp:124:57: current parser token ';'
2. vm/free_list_allocator.hpp:1:1: parsing namespace 'factor'
3. vm/free_list_allocator.hpp:123:68: parsing function body 'sweep'
4. vm/free_list_allocator.hpp:123:68: in compound statement ('{}')
clang: error: unable to execute command: Segmentation fault
https://lists.sourceforge.net/lists/listinfo/factor-talk
--
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
--
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
--
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] gcc versions
I missed your point.
We decided to use C++11 features a few months ago, so we need whatever it
takes to compile that correctly.
Maybe we need to switch to cmake or modify factor.sh to check that the
compiler version is high enough.
It sucks that Debian is shipping a buggy compiler with a stable release.
On Fri, Aug 14, 2015 at 11:10 AM, Jon Harper jon.harpe...@gmail.com wrote:
So if the fix is correct, then we are all good.
The implicit this fix doesn't change anything:
With Wheezy's clang, it has no effect: it always segfaults during the
precompilation of master.hpp
With Wheezy's gcc, it goes from a false negative error during the
precompilation of master.hpp to a segfault during the compilation of
compaction.cpp
Also, there are tons of other implicit this uses. This one just happens to
be in a lambda and calling a non const method of this.
I'm not sure we want to support 2012's compilers ?
Jon
On Fri, Aug 14, 2015 at 7:54 PM, Doug Coleman doug.cole...@gmail.com
wrote:
Interesting. Both versions work with my clang.
ergmac:factor erg$ [master*] clang --version
Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn)
Target: x86_64-apple-darwin14.4.0
Thread model: posix
So if the fix is correct, then we are all good.
Doug
On Fri, Aug 14, 2015 at 10:51 AM, Jon Harper jon.harpe...@gmail.com
wrote:
Well that's GCC 4.7.2 https://gcc.gnu.org/gcc-4.7/ September 20, 2012
Gcc did fix this in GCC 4.7.3 https://gcc.gnu.org/gcc-4.7/ April 11,
2013
Also, clang does not error on the implicit this, but crashes hard
earlier than gcc :)
$ clang --version
Debian clang version 3.0-6.2 (tags/RELEASE_30/final) (based on LLVM 3.0)
Target: i386-pc-linux-gnu
Thread model: posix
$ CC=clang CXX=clang++ make
make `./build-support/factor.sh make-target`
[...snip...]
1. vm/free_list_allocator.hpp:124:57: current parser token ';'
2. vm/free_list_allocator.hpp:1:1: parsing namespace 'factor'
3. vm/free_list_allocator.hpp:123:68: parsing function body 'sweep'
4. vm/free_list_allocator.hpp:123:68: in compound statement ('{}')
clang: error: unable to execute command: Segmentation fault
https://lists.sourceforge.net/lists/listinfo/factor-talk
--
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
--
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
--
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
--
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] gcc versions
I started this discussion because I thought that not everybody was aware of
the impact of the recent c++11 changes. We now have stronger requirements
than most projects, but this also means we have cleaner c++ code :) I think
that's worth it.
I'll test with different gcc and clang versions so we can add a check in
factor.sh.
Note: Wheezy is now oldstable, so has been obsolete for 4 months (it
still gets security fixes until february 2016, and after that debian's LTS
until 2018).
Jon
On Fri, Aug 14, 2015 at 7:54 PM, John Benediktsson mrj...@gmail.com wrote:
Are we using too-bleeding-edge C++ features?
Is the suggestion maybe we scale down to some subset compilers have had
working for 3-4 years?
On Aug 14, 2015, at 10:51 AM, Jon Harper jon.harpe...@gmail.com wrote:
Well that's GCC 4.7.2 https://gcc.gnu.org/gcc-4.7/ September 20, 2012
Gcc did fix this in GCC 4.7.3 https://gcc.gnu.org/gcc-4.7/ April 11,
2013
Also, clang does not error on the implicit this, but crashes hard earlier
than gcc :)
$ clang --version
Debian clang version 3.0-6.2 (tags/RELEASE_30/final) (based on LLVM 3.0)
Target: i386-pc-linux-gnu
Thread model: posix
$ CC=clang CXX=clang++ make
make `./build-support/factor.sh make-target`
[...snip...]
1. vm/free_list_allocator.hpp:124:57: current parser token ';'
2. vm/free_list_allocator.hpp:1:1: parsing namespace 'factor'
3. vm/free_list_allocator.hpp:123:68: parsing function body 'sweep'
4. vm/free_list_allocator.hpp:123:68: in compound statement ('{}')
clang: error: unable to execute command: Segmentation fault
https://lists.sourceforge.net/lists/listinfo/factor-talk
--
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
--
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
--
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] gcc versions
Cool. Here's an issue for it:
https://github.com/slavapestov/factor/issues/1440
On Fri, Aug 14, 2015 at 1:31 PM, Jon Harper jon.harpe...@gmail.com wrote:
I started this discussion because I thought that not everybody was aware
of the impact of the recent c++11 changes. We now have stronger
requirements than most projects, but this also means we have cleaner c++
code :) I think that's worth it.
I'll test with different gcc and clang versions so we can add a check in
factor.sh.
Note: Wheezy is now oldstable, so has been obsolete for 4 months (it
still gets security fixes until february 2016, and after that debian's LTS
until 2018).
Jon
On Fri, Aug 14, 2015 at 7:54 PM, John Benediktsson mrj...@gmail.com
wrote:
Are we using too-bleeding-edge C++ features?
Is the suggestion maybe we scale down to some subset compilers have had
working for 3-4 years?
On Aug 14, 2015, at 10:51 AM, Jon Harper jon.harpe...@gmail.com wrote:
Well that's GCC 4.7.2 https://gcc.gnu.org/gcc-4.7/ September 20, 2012
Gcc did fix this in GCC 4.7.3 https://gcc.gnu.org/gcc-4.7/ April 11,
2013
Also, clang does not error on the implicit this, but crashes hard earlier
than gcc :)
$ clang --version
Debian clang version 3.0-6.2 (tags/RELEASE_30/final) (based on LLVM 3.0)
Target: i386-pc-linux-gnu
Thread model: posix
$ CC=clang CXX=clang++ make
make `./build-support/factor.sh make-target`
[...snip...]
1. vm/free_list_allocator.hpp:124:57: current parser token ';'
2. vm/free_list_allocator.hpp:1:1: parsing namespace 'factor'
3. vm/free_list_allocator.hpp:123:68: parsing function body 'sweep'
4. vm/free_list_allocator.hpp:123:68: in compound statement ('{}')
clang: error: unable to execute command: Segmentation fault
https://lists.sourceforge.net/lists/listinfo/factor-talk
--
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
--
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
--
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
--
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
