date:20201122

Re: [Factor-talk] Peg Parser Definition

2020-11-22 Thread Alexander Ilin

Thanks for the [=[ suggestion, it works just as well! 22.11.2020, 19:17, "John Benediktsson" :Yes, here's how (currently depending on the implementation behavior, but this has worked for a long time). For example, in the urls.private vocabulary there's a parser for URLs, and you can get the peg parser from an EBNF: word. \ parse-url "ebnf-parser" word-prop main of Most of our EBNF: words have been converted to use multiline strings, which avoid the escaping issue if you want to do the same: EBNF-PARSER: word [=[ ... EBNF string ... ]=] I've gone back and forth with triple-quote strings.  They exist in some languages, but they also make parsing single quote strings a bit more difficult.  We removed them while working on some new parser techniques, and the multilline vocabulary has a few other options like the example above.  If people think we really should have them, we could revisit it. Best,John.  On Sun, Nov 22, 2020 at 1:44 AM Alexander Ilin  wrote:Hello!  I'd like to use the peg.search vocab, and for that I need to pass it a parser.  Most of the parsing words in peg.ebnf produce either a quotation that is immediately called inline (EBNF[[), or produce a word that calls a parser hidden inside it (EBNF:).  There are only two ways to pass a parser to peg.search:search: construct it from words without using the EBNF syntax, or by using the undocumented EBNF-PARSER: word.  I managed to figure out how the EBNF-PARSER: works, and the unfortunate thing about it is that the syntax is the following:EBNF-PARSER: word "...EBNF string..."  The word will be what we need: ( -- parser ).  The unfortunate part is that it's very annoying having to escape all the double quotes in the "EBNF string".  So, now I have two questions.  1. Is it possible to convert a word defined with EBNF: into a word returning a parser, or to somehow extract the parser from inside it? Is there maybe an undocumented word that could help with that, like by making a wrapper?  2. Is it possible to return the """ (triple double quoted) string syntax, which doesn't require escaping single double quotes inside them?---=--- Александр___Factor-talk mailing listFactor-talk@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/factor-talk,,___Factor-talk mailing listFactor-talk@lists.sourceforge.nethttps://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] Peg Parser Performance

2020-11-22 Thread Alexander Ilin

If I remove all => actions, the time goes down to 120 seconds.  23.11.2020, 00:18, "John Benediktsson" :I suspect it’s a lot of “swap prefix >string” type stuff that’s different, but I can help you profile this a little later today or tomorrow.   On Nov 22, 2020, at 1:07 PM, Alexander Ilin  wrote: Hello!  I put the code into a vocab, restarted the Listener and repeated the test like so: IN: log-db EBNF: parse-csv-line [=[   quotedColumn = "\""~ (!("\"") .)* "\""~ quotedColumn*       => [[ first2 swap prefix [ >string ] map "\"" join ]]   unquotedColumn = (!("\t") .)*   column = ( quotedColumn | unquotedColumn ) => [[ >string ]]   rule = column ( "\t"~ column )* => [[ first2 swap prefix ]]]=]: parse ( file -- ast )   [ utf8 [       input-stream get [ parse-csv-line , ] each-stream-line   ] with-file-reader ] { } make ;   In Listener: USE: log-db now "file-name.csv" parse now rot time- The resulting run time is 180 seconds, which is fewer than 200, but not that much closer to 2.Somehow the optimizations don't seem to be helping a lot here. 22.11.2020, 22:51, "John Benediktsson" :When you run that in the listener it uses the non optimizing compiler.You should use the EBNF: word [=[ ... ]=] form and then refer to word for it to be a compiled parser.It’ll be much faster.Or wrap all that in a : foo ( — ) ... ;  On Nov 22, 2020, at 11:49 AM, Alexander Ilin  wrote:  Hello!   I've got my first test results, and I'm having some doubts.   The following code runs almost 200 seconds on a 20Mb file:  "file-name.csv" [ utf8 [ input-stream get[EBNF[=[  quotedColumn = "\""~ (!("\"") .)* "\""~ quotedColumn*=> [[ first2 swap prefix [ >string ] map "\"" join ]]  unquotedColumn = (!("\t") .)*  column = ( quotedColumn | unquotedColumn ) => [[ >string ]]  rule = column ( "\t"~ column )* => [[ first2 swap prefix ]]]=] ,] each-stream-line ] with-file-reader ] { } makeThe following equivalent code using the csv vocab runs about 2 seconds on the same file:  "file-name.csv" [ utf8 [ input-stream get CHAR: \t [[ string>csv [ first , ] unless-empty ] each-stream-line ] with-delimiter ] with-file-reader ] { } makeThe difference is 100x, and the question is: is the speed difference related to the fact that I'm running the code in the Listener? Could it be that if I put it all into a vocab as opposed to running interactively it would get better optimized and reach the performance of the csv vocab?  ---=--- Александр___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk___Factor-talk mailing listFactor-talk@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/factor-talk  ---=---Александр ___Factor-talk mailing listFactor-talk@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/factor-talk,,___Factor-talk mailing listFactor-talk@lists.sourceforge.nethttps://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] Peg Parser Performance

2020-11-22 Thread John Benediktsson

I suspect it’s a lot of “swap prefix >string” type stuff that’s different, but 
I can help you profile this a little later today or tomorrow. 


> On Nov 22, 2020, at 1:07 PM, Alexander Ilin  wrote:
> 
> 
> Hello!
>  
>  I put the code into a vocab, restarted the Listener and repeated the test 
> like so:
>  
> IN: log-db
>  
> EBNF: parse-csv-line [=[
>quotedColumn = "\""~ (!("\"") .)* "\""~ quotedColumn*
>=> [[ first2 swap prefix [ >string ] map "\"" join ]]
>unquotedColumn = (!("\t") .)*
>column = ( quotedColumn | unquotedColumn ) => [[ >string ]]
>rule = column ( "\t"~ column )* => [[ first2 swap prefix ]]
> ]=]
> 
> : parse ( file -- ast )
>[ utf8 [
>input-stream get [ parse-csv-line , ] each-stream-line
>] with-file-reader ] { } make ;
>  
>  
>  
> In Listener:
>  
> USE: log-db now "file-name.csv" parse now rot time-
>  
> The resulting run time is 180 seconds, which is fewer than 200, but not that 
> much closer to 2.
> Somehow the optimizations don't seem to be helping a lot here.
>  
> 22.11.2020, 22:51, "John Benediktsson" :
> When you run that in the listener it uses the non optimizing compiler.
> 
> You should use the EBNF: word [=[ ... ]=] form and then refer to word for it 
> to be a compiled parser.
> 
> It’ll be much faster.
> 
> Or wrap all that in a : foo ( — ) ... ;
> 
> 
>  
> 
>  On Nov 22, 2020, at 11:49 AM, Alexander Ilin  wrote:
>  
>  Hello!
>  
>   I've got my first test results, and I'm having some doubts.
>  
>   The following code runs almost 200 seconds on a 20Mb file:
>  
>  "file-name.csv" [ utf8 [ input-stream get
> [
> EBNF[=[
>   quotedColumn = "\""~ (!("\"") .)* "\""~ quotedColumn*
> => [[ first2 swap prefix [ >string ] map "\"" join ]]
>   unquotedColumn = (!("\t") .)*
>   column = ( quotedColumn | unquotedColumn ) => [[ >string ]]
>   rule = column ( "\t"~ column )* => [[ first2 swap prefix ]]
> ]=] ,
> ] each-stream-line
>  ] with-file-reader ] { } make
>  
>  
>   The following equivalent code using the csv vocab runs about 2 seconds on 
> the same file:
>  
>  "file-name.csv" [ utf8 [ input-stream get CHAR: \t [
> [ string>csv [ first , ] unless-empty ] each-stream-line
>  ] with-delimiter ] with-file-reader ] { } make
>  
>  
>   The difference is 100x, and the question is: is the speed difference 
> related to the fact that I'm running the code in the Listener? Could it be 
> that if I put it all into a vocab as opposed to running interactively it 
> would get better optimized and reach the performance of the csv vocab?
>  
>  ---=---
>  Александр
>  
>  
>  
>  ___
>  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] Peg Parser Performance

2020-11-22 Thread Alexander Ilin

Hello!  I put the code into a vocab, restarted the Listener and repeated the test like so: IN: log-db EBNF: parse-csv-line [=[   quotedColumn = "\""~ (!("\"") .)* "\""~ quotedColumn*       => [[ first2 swap prefix [ >string ] map "\"" join ]]   unquotedColumn = (!("\t") .)*   column = ( quotedColumn | unquotedColumn ) => [[ >string ]]   rule = column ( "\t"~ column )* => [[ first2 swap prefix ]]]=]: parse ( file -- ast )   [ utf8 [       input-stream get [ parse-csv-line , ] each-stream-line   ] with-file-reader ] { } make ;   In Listener: USE: log-db now "file-name.csv" parse now rot time- The resulting run time is 180 seconds, which is fewer than 200, but not that much closer to 2.Somehow the optimizations don't seem to be helping a lot here. 22.11.2020, 22:51, "John Benediktsson" :When you run that in the listener it uses the non optimizing compiler.You should use the EBNF: word [=[ ... ]=] form and then refer to word for it to be a compiled parser.It’ll be much faster.Or wrap all that in a : foo ( — ) ... ;  On Nov 22, 2020, at 11:49 AM, Alexander Ilin  wrote:  Hello!   I've got my first test results, and I'm having some doubts.   The following code runs almost 200 seconds on a 20Mb file:  "file-name.csv" [ utf8 [ input-stream get[EBNF[=[  quotedColumn = "\""~ (!("\"") .)* "\""~ quotedColumn*=> [[ first2 swap prefix [ >string ] map "\"" join ]]  unquotedColumn = (!("\t") .)*  column = ( quotedColumn | unquotedColumn ) => [[ >string ]]  rule = column ( "\t"~ column )* => [[ first2 swap prefix ]]]=] ,] each-stream-line ] with-file-reader ] { } makeThe following equivalent code using the csv vocab runs about 2 seconds on the same file:  "file-name.csv" [ utf8 [ input-stream get CHAR: \t [[ string>csv [ first , ] unless-empty ] each-stream-line ] with-delimiter ] with-file-reader ] { } makeThe difference is 100x, and the question is: is the speed difference related to the fact that I'm running the code in the Listener? Could it be that if I put it all into a vocab as opposed to running interactively it would get better optimized and reach the performance of the csv vocab?  ---=--- Александр___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk___Factor-talk mailing listFactor-talk@lists.sourceforge.nethttps://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] Factor and MacOS arm64

2020-11-22 Thread John Benediktsson

Right now the compiler doesn’t make a correct boot quotation to jump into after 
the binary loads the factor image. 

My M1 technically comes in a couple days, so I hope to help with the effort 
soon!

Doug worked on the arm64 assembler and now we have to implement the compiler 
hooks properly with assembly output. 

More to come soon!

Thanks for trying it out!


> On Nov 22, 2020, at 12:09 PM, Steve Davies  wrote:
> 
> 
> 
> 
>> On Sun, 22 Nov 2020 at 20:30, John Benediktsson  wrote:
>> It is being worked on in the arm64 branch on GitHub. 
>> 
> 
> Ah - gotcha.
> 
> I do know ARM assembly, but I know so little about Factor I doubt I can 
> contribute much.
> 
> I checked out the arm64 branch and I see it compiles!
> 
> If I run the one in vm-arm64 I get an abort:
> 
> steve@maira vm-arm64 % ./factor-arm64 
> fatal_error: Out of memory in mmap: 0x48000
> zsh: abort  ../../../vm-arm64/factor-arm64
> 
> Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
> 0   libsystem_kernel.dylib0x00019b4c3cec __pthread_kill + 8
> 1   libsystem_pthread.dylib   0x00019b4f4c24 pthread_kill + 292
> 2   libsystem_c.dylib 0x00019b43c864 abort + 104
> 3   factor-arm64  0x0001024b98ec factor::abort() + 52
> 4   factor-arm64  0x0001024d66b8 
> factor::fatal_error(char const*, unsigned long) + 336
> 5   factor-arm64  0x0001024b86fc 
> factor::segment::segment(unsigned long, bool) + 116
> 6   factor-arm64  0x0001024c7440 
> factor::callback_heap::callback_heap(unsigned long, factor::factor_vm*) + 56
> 7   factor-arm64  0x0001024d7174 
> factor::factor_vm::init_factor(factor::vm_parameters*) + 268
> 8   factor-arm64  0x0001024d74dc 
> factor::factor_vm::start_standalone_factor(int, char**) + 68
> 9   factor-arm64  0x0001024d7698 
> start_standalone_factor + 44
> 10  factor-arm64  0x0001024e7210 main + 36
> 11  libdyld.dylib 0x00019b510f54 start + 4
> 
> 
> 
> If I run the one in the app bundle:it is "killed":
> 
> Exception Type:EXC_BAD_ACCESS (Code Signature Invalid)
> Exception Codes:   0x0032, 0x0001020dc000
> Exception Note:EXC_CORPSE_NOTIFY
> 
> Perhaps there is a code-signing problem since the original binary was called 
> factor-arm64 ?  Or maybe I didn't build the code the right way (I used some 
> combination of "compile" and "self-update").
> 
> Steve
> 
> 
> 
> 
> 
> ___
> 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] Factor and MacOS arm64

2020-11-22 Thread Steve Davies

On Sun, 22 Nov 2020 at 20:30, John Benediktsson  wrote:

> It is being worked on in the arm64 branch on GitHub.
>
>
Ah - gotcha.

I do know ARM assembly, but I know so little about Factor I doubt I can
contribute much.

I checked out the arm64 branch and I see it compiles!

If I run the one in vm-arm64 I get an abort:

steve@maira vm-arm64 % ./factor-arm64
fatal_error: Out of memory in mmap: 0x48000
zsh: abort  ../../../vm-arm64/factor-arm64

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib 0x00019b4c3cec __pthread_kill + 8
1   libsystem_pthread.dylib   0x00019b4f4c24 pthread_kill + 292
2   libsystem_c.dylib 0x00019b43c864 abort + 104
3   factor-arm64   0x0001024b98ec factor::abort() + 52
4   factor-arm64   0x0001024d66b8
factor::fatal_error(char const*, unsigned long) + 336
5   factor-arm64   0x0001024b86fc
factor::segment::segment(unsigned long, bool) + 116
6   factor-arm64   0x0001024c7440
factor::callback_heap::callback_heap(unsigned long, factor::factor_vm*) + 56
7   factor-arm64   0x0001024d7174
factor::factor_vm::init_factor(factor::vm_parameters*) + 268
8   factor-arm64   0x0001024d74dc
factor::factor_vm::start_standalone_factor(int, char**) + 68
9   factor-arm64   0x0001024d7698
start_standalone_factor + 44
10  factor-arm64   0x0001024e7210 main + 36
11  libdyld.dylib 0x00019b510f54 start + 4



If I run the one in the app bundle:it is "killed":

Exception Type:EXC_BAD_ACCESS (Code Signature Invalid)
Exception Codes:   0x0032, 0x0001020dc000
Exception Note:EXC_CORPSE_NOTIFY

Perhaps there is a code-signing problem since the original binary was
called factor-arm64 ?  Or maybe I didn't build the code the right way (I
used some combination of "compile" and "self-update").

Steve
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk

Re: [Factor-talk] Peg Parser Performance

2020-11-22 Thread John Benediktsson

When you run that in the listener it uses the non optimizing compiler. 

You should use the EBNF: word [=[ ... ]=] form and then refer to word for it to 
be a compiled parser. 

It’ll be much faster. 

Or wrap all that in a : foo ( — ) ... ;



> On Nov 22, 2020, at 11:49 AM, Alexander Ilin  wrote:
> 
> Hello!
> 
>  I've got my first test results, and I'm having some doubts.
> 
>  The following code runs almost 200 seconds on a 20Mb file:
> 
> "file-name.csv" [ utf8 [ input-stream get
>[
>EBNF[=[
>  quotedColumn = "\""~ (!("\"") .)* "\""~ quotedColumn*
>=> [[ first2 swap prefix [ >string ] map "\"" join ]]
>  unquotedColumn = (!("\t") .)*
>  column = ( quotedColumn | unquotedColumn ) => [[ >string ]]
>  rule = column ( "\t"~ column )* => [[ first2 swap prefix ]]
>]=] ,
>] each-stream-line
> ] with-file-reader ] { } make
> 
> 
>  The following equivalent code using the csv vocab runs about 2 seconds on 
> the same file:
> 
> "file-name.csv" [ utf8 [ input-stream get CHAR: \t [
>[ string>csv [ first , ] unless-empty ] each-stream-line
> ] with-delimiter ] with-file-reader ] { } make
> 
> 
>  The difference is 100x, and the question is: is the speed difference related 
> to the fact that I'm running the code in the Listener? Could it be that if I 
> put it all into a vocab as opposed to running interactively it would get 
> better optimized and reach the performance of the csv vocab?
> 
> ---=--- 
> Александр
> 
> 
> 
> ___
> 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] Peg Parser Performance

2020-11-22 Thread Alexander Ilin

Hello!

  I've got my first test results, and I'm having some doubts.

  The following code runs almost 200 seconds on a 20Mb file:

"file-name.csv" [ utf8 [ input-stream get
[
EBNF[=[
  quotedColumn = "\""~ (!("\"") .)* "\""~ quotedColumn*
=> [[ first2 swap prefix [ >string ] map "\"" join ]]
  unquotedColumn = (!("\t") .)*
  column = ( quotedColumn | unquotedColumn ) => [[ >string ]]
  rule = column ( "\t"~ column )* => [[ first2 swap prefix ]]
]=] ,
] each-stream-line
] with-file-reader ] { } make


  The following equivalent code using the csv vocab runs about 2 seconds on the 
same file:

"file-name.csv" [ utf8 [ input-stream get CHAR: \t [
[ string>csv [ first , ] unless-empty ] each-stream-line
] with-delimiter ] with-file-reader ] { } make


  The difference is 100x, and the question is: is the speed difference related 
to the fact that I'm running the code in the Listener? Could it be that if I 
put it all into a vocab as opposed to running interactively it would get better 
optimized and reach the performance of the csv vocab?

---=--- 
 Александр



___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk

Re: [Factor-talk] Factor and MacOS arm64

2020-11-22 Thread John Benediktsson

It is being worked on in the arm64 branch on GitHub. 

It requires some additional compiler support within Factor, but since Doug and 
I both now have shiny new M1 computers, we both have good incentive to get it 
working. 

If you have knowledge of ARM assembly and want to help, that would be great.

I *think* it can work under Rosetta2, with some library dependency limitations. 

Best,
John.

> On Nov 22, 2020, at 10:25 AM, Steve Davies  wrote:
> 
> 
> Hi,
> 
> What would it take to build Factor for the MacOS M1 (arm64) systems?
> 
> I do see in the code that there is some stuff for Linux ARM, which I think is 
> actually complete (I'll try to build it on a Raspberry Pi tomorrow).  There 
> is also some stuff in build.sh for Apple iPhone/IPad hardware with arm64 
> processor, but as far as I can see this is not complete.
> 
> What is the state of Factor on arm?  Was arm64 ever attempted?  
> 
> I guess to get it built requires some blend of the Darwin work and the arm 
> stuff.
> 
> I did some basic tinkering in the build side and got a little bit along.  
> Well I got as far as errors...
> 
> In file included from vm/master.hpp:116:
> vm/code_blocks.hpp:74:33: error: no member named 'flush_icache' in namespace 
> 'factor'
>   void flush_icache() { factor::flush_icache((cell)this, size()); }
> ^
> And etc.  Well that's no surprise.  Is there any insight or porting guide as 
> to what Factor needs to run in a new environment like this?
> 
> Thanks,
> Steve
> 
> -
> 
> diff --git a/GNUmakefile b/GNUmakefile
> index babefb19e9..2012f20bf8 100644
> --- a/GNUmakefile
> +++ b/GNUmakefile
> @@ -188,6 +188,10 @@ macosx-x86-64:
>  macosx-x86-fat:
> $(MAKE) $(ALL) macosx.app CONFIG=vm/Config.macosx.x86.fat
>  
> +macosx-arm64-64:
> +   $(MAKE) $(ALL) macosx.app CONFIG=vm/Config.macosx.arm64.64
> +
>  linux-x86-32:
> $(MAKE) $(ALL) CONFIG=vm/Config.linux.x86.32
>  
> diff --git a/build.sh b/build.sh
> index 490c9ac02a..9b32d4d87d 100755
> --- a/build.sh
> +++ b/build.sh
> @@ -299,6 +299,7 @@ find_architecture() {
> i86pc) ARCH=x86;;
> amd64) ARCH=x86;;
> ppc64) ARCH=ppc;;
> +   arm64) ARCH=arm64;;
> *86) ARCH=x86;;
> *86_64) ARCH=x86;;
> aarch64) ARCH=arm64;;
> diff --git a/vm/master.hpp b/vm/master.hpp
> index bac9e5f7ed..86edfaa628 100644
> --- a/vm/master.hpp
> +++ b/vm/master.hpp
> @@ -64,6 +64,9 @@
>  // Detect target CPU type
>  #if defined(__arm__)
>  #define FACTOR_ARM
> +#elif defined(__arm64__)
> +#define FACTOR_ARM
> +#define FACTOR_64
>  #elif defined(__amd64__) || defined(__x86_64__) || defined(_M_AMD64)
>  #define FACTOR_AMD64
>  #define FACTOR_64
> diff --git a/vm/platform.hpp b/vm/platform.hpp
> index c72b7b6334..8c4b39012a 100644
> --- a/vm/platform.hpp
> +++ b/vm/platform.hpp
> @@ -22,6 +22,8 @@
>#include "os-macosx-x86.32.hpp"
>  #elif defined(FACTOR_AMD64)
>#include "os-macosx-x86.64.hpp"
> +#elif defined(FACTOR_ARM)
> +  #include "os-macosx-arm64-64.hpp"
>  #else
>#error "Unsupported Mac OS X flavor"
>  #endif
> 
> I also made a vm/os-macosx-arm64-64.hpp but of course I'm now already out of 
> my depth since I have no understanding of the Factor implementation.
> 
> ___
> 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] Factor and MacOS arm64

2020-11-22 Thread Steve Davies

Hi,

What would it take to build Factor for the MacOS M1 (arm64) systems?

I do see in the code that there is some stuff for Linux ARM, which I think
is actually complete (I'll try to build it on a Raspberry Pi tomorrow).
There is also some stuff in build.sh for Apple iPhone/IPad hardware with
arm64 processor, but as far as I can see this is not complete.

What is the state of Factor on arm?  Was arm64 ever attempted?

I guess to get it built requires some blend of the Darwin work and the arm
stuff.

I did some basic tinkering in the build side and got a little bit along.
Well I got as far as errors...

In file included from vm/master.hpp:116:

vm/code_blocks.hpp:74:33: error: no member named 'flush_icache' in
namespace 'factor'

  void flush_icache() { factor::flush_icache((cell)this, size()); }

^
And etc.  Well that's no surprise.  Is there any insight or porting guide
as to what Factor needs to run in a new environment like this?

Thanks,
Steve

-

diff --git a/GNUmakefile b/GNUmakefile
index babefb19e9..2012f20bf8 100644
--- a/GNUmakefile
+++ b/GNUmakefile
@@ -188,6 +188,10 @@ macosx-x86-64:
 macosx-x86-fat:
$(MAKE) $(ALL) macosx.app CONFIG=vm/Config.macosx.x86.fat

+macosx-arm64-64:
+   $(MAKE) $(ALL) macosx.app CONFIG=vm/Config.macosx.arm64.64
+
 linux-x86-32:
$(MAKE) $(ALL) CONFIG=vm/Config.linux.x86.32

diff --git a/build.sh b/build.sh
index 490c9ac02a..9b32d4d87d 100755
--- a/build.sh
+++ b/build.sh
@@ -299,6 +299,7 @@ find_architecture() {
i86pc) ARCH=x86;;
amd64) ARCH=x86;;
ppc64) ARCH=ppc;;
+   arm64) ARCH=arm64;;
*86) ARCH=x86;;
*86_64) ARCH=x86;;
aarch64) ARCH=arm64;;
diff --git a/vm/master.hpp b/vm/master.hpp
index bac9e5f7ed..86edfaa628 100644
--- a/vm/master.hpp
+++ b/vm/master.hpp
@@ -64,6 +64,9 @@
 // Detect target CPU type
 #if defined(__arm__)
 #define FACTOR_ARM
+#elif defined(__arm64__)
+#define FACTOR_ARM
+#define FACTOR_64
 #elif defined(__amd64__) || defined(__x86_64__) || defined(_M_AMD64)
 #define FACTOR_AMD64
 #define FACTOR_64
diff --git a/vm/platform.hpp b/vm/platform.hpp
index c72b7b6334..8c4b39012a 100644
--- a/vm/platform.hpp
+++ b/vm/platform.hpp
@@ -22,6 +22,8 @@
   #include "os-macosx-x86.32.hpp"
 #elif defined(FACTOR_AMD64)
   #include "os-macosx-x86.64.hpp"
+#elif defined(FACTOR_ARM)
+  #include "os-macosx-arm64-64.hpp"
 #else
   #error "Unsupported Mac OS X flavor"
 #endif

I also made a vm/os-macosx-arm64-64.hpp but of course I'm now already out
of my depth since I have no understanding of the Factor implementation.
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk

Re: [Factor-talk] Peg Parser Definition

2020-11-22 Thread John Benediktsson

Yes, here's how (currently depending on the implementation behavior, but
this has worked for a long time).

For example, in the urls.private vocabulary there's a parser for URLs, and
you can get the peg parser from an EBNF: word.

\ parse-url "ebnf-parser" word-prop main of

Most of our EBNF: words have been converted to use multiline strings, which
avoid the escaping issue if you want to do the same:

EBNF-PARSER: word [=[ ... EBNF string ... ]=]

I've gone back and forth with triple-quote strings.  They exist in some
languages, but they also make parsing single quote strings a bit more
difficult.  We removed them while working on some new parser techniques,
and the multilline vocabulary has a few other options like the example
above.  If people think we really should have them, we could revisit it.

Best,
John.

On Sun, Nov 22, 2020 at 1:44 AM Alexander Ilin  wrote:

> Hello!
>
>   I'd like to use the peg.search vocab, and for that I need to pass it a
> parser.
>   Most of the parsing words in peg.ebnf produce either a quotation that is
> immediately called inline (EBNF[[), or produce a word that calls a parser
> hidden inside it (EBNF:).
>   There are only two ways to pass a parser to peg.search:search: construct
> it from words without using the EBNF syntax, or by using the undocumented
> EBNF-PARSER: word.
>
>   I managed to figure out how the EBNF-PARSER: works, and the unfortunate
> thing about it is that the syntax is the following:
>
> EBNF-PARSER: word "...EBNF string..."
>
>   The word will be what we need: ( -- parser ).
>   The unfortunate part is that it's very annoying having to escape all the
> double quotes in the "EBNF string".
>
>   So, now I have two questions.
>   1. Is it possible to convert a word defined with EBNF: into a word
> returning a parser, or to somehow extract the parser from inside it? Is
> there maybe an undocumented word that could help with that, like by making
> a wrapper?
>   2. Is it possible to return the """ (triple double quoted) string
> syntax, which doesn't require escaping single double quotes inside them?
>
> ---=---
>  Александр
>
>
>
> ___
> 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] Peg Parsing Files

2020-11-22 Thread John Benediktsson

Right now this is true:

binary  stream-seekable?

But none of the decoders allow stream-seeking.  Maybe we should support
that for ascii and other 8-bit encodings...

On Sun, Nov 22, 2020 at 3:17 PM Jon Harper  wrote:

> I didn't know about the seekable streams implementation in factor:
> https://docs.factorcode.org/content/article-stream-protocol.html
>
> We have:
>  "/tmp/toto" ascii  stream-seekable?
> f
>
>  "/tmp/toto" (file-reader)
> t
> ! it works, stream-seek can rewind or fast forward and stream-read1
> will get the bytes
>
> For some variable length encodings (utf8), seeking is going to be
> pretty expensive, but for ascii it's transparent so maybe it should
> work in  ?
>
> Anyway you're right, although the peg vocabulary currently uses the
> sequence protocol (mainly through slices from what I see), maybe it
> could be rewritten to use the seekable stream protocol ? Still seems
> like quite a lot of work though.
>
> Jon
>
> On Sat, Nov 21, 2020 at 11:49 PM Alexander Ilin  wrote:
> >
> > What's the problem backtracking through a file? Streams can have
> arbitrary positioning.
> >
> > Alternatively, there must be a simple way to "wrap" a random access file
> stream with an array-like interface, right? Don't we have a class like that
> somewhere?
> >
> > Like the reverse of  and ?
> >
> > I will definitely use the tokenizers, thanks.
> >
> > 22.11.2020, 01:34, "Jon Harper" :
> >
> > What you are describing reminds me of the built-in nesting of parsers
> with the ebnf tokenizer :
> https://docs.factorcode.org/content/article-peg.ebnf.tokenizers.html
> >
> > Not sure if it's really applicable to your use case though.
> >
> >
> > As for streams, aren't packrat parsers backtracking (with memoization)?
> So no?
> >
> >
> >
> > ___
> > 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] Peg Parsing Files

2020-11-22 Thread Jon Harper

I didn't know about the seekable streams implementation in factor:
https://docs.factorcode.org/content/article-stream-protocol.html

We have:
 "/tmp/toto" ascii  stream-seekable?
f

 "/tmp/toto" (file-reader)
t
! it works, stream-seek can rewind or fast forward and stream-read1
will get the bytes

For some variable length encodings (utf8), seeking is going to be
pretty expensive, but for ascii it's transparent so maybe it should
work in  ?

Anyway you're right, although the peg vocabulary currently uses the
sequence protocol (mainly through slices from what I see), maybe it
could be rewritten to use the seekable stream protocol ? Still seems
like quite a lot of work though.

Jon

On Sat, Nov 21, 2020 at 11:49 PM Alexander Ilin  wrote:
>
> What's the problem backtracking through a file? Streams can have arbitrary 
> positioning.
>
> Alternatively, there must be a simple way to "wrap" a random access file 
> stream with an array-like interface, right? Don't we have a class like that 
> somewhere?
>
> Like the reverse of  and ?
>
> I will definitely use the tokenizers, thanks.
>
> 22.11.2020, 01:34, "Jon Harper" :
>
> What you are describing reminds me of the built-in nesting of parsers with 
> the ebnf tokenizer : 
> https://docs.factorcode.org/content/article-peg.ebnf.tokenizers.html
>
> Not sure if it's really applicable to your use case though.
>
>
> As for streams, aren't packrat parsers backtracking (with memoization)? So no?
>
>
>
> ___
> 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] Peg Parser Definition

Re: [Factor-talk] Peg Parser Performance

Re: [Factor-talk] Peg Parser Performance

Re: [Factor-talk] Peg Parser Performance

Re: [Factor-talk] Factor and MacOS arm64

Re: [Factor-talk] Factor and MacOS arm64

Re: [Factor-talk] Peg Parser Performance

[Factor-talk] Peg Parser Performance

Re: [Factor-talk] Factor and MacOS arm64

[Factor-talk] Factor and MacOS arm64

Re: [Factor-talk] Peg Parser Definition

Re: [Factor-talk] Peg Parsing Files

Re: [Factor-talk] Peg Parsing Files

13 matches

Site Navigation

Mail list logo

Footer information