date:20161125

Re: [Factor-talk] Actors on Screen

2016-11-25 Thread Alexander Ilin

Hello!

25.11.2016, 22:07, "John Benediktsson" :
> We have a game vocabulary framework that could be useful for you. I would 
> think separate threads would be a little less clear than an update method on 
> all your objects you run every frame or so often.

  Looks very interesting! Too bad there are no demos.

  Is Joe Groff available for comments? He seems to be the main author.

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

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

Re: [Factor-talk] Actors on Screen

2016-11-25 Thread John Benediktsson

We have a game vocabulary framework that could be useful for you.  I would 
think separate threads would be a little less clear than an update method on 
all your objects you run every frame or so often. 

> On Nov 25, 2016, at 10:36 AM, Alexander Ilin  wrote:
> 
> Hello!
> 
> 25.11.2016, 21:27, "John Benediktsson" :
>> You can probably use a bunch of models that hold their state/location and 
>> the UI renders them. Each thread can update the model's value when it 
>> changes?
>> 
>> What kind of library were you thinking you needed?
> 
>  Oh, I dunno. Something someone developed for a simple 2d-game or a 
> flash-like animation platform.
> 
>  Actually, I've no experience in these things, so I wanted to read something 
> to get the idea how people conceptualize and approach such tasks.
> 
>  What I actually need is a way to model and visualize a bunch of robots and a 
> conveyor line so I can develop a control strategy and work out some 
> corner-case scenarios. I have a bunch of constraints, and I need to create an 
> understanding of the way to command the robots for optimal conveyor 
> throughput.
> 
> In fact, I have a rough understanding of the control algorithm, I just wanted 
> to see it in motion and work out the details. A rewindable timeline would be 
> very helpful.
> 
>  Any ideas?
> 
> ---=--- 
> Александр
> 
> --
> ___
> 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] Actors on Screen

2016-11-25 Thread Alexander Ilin

Hello!

25.11.2016, 21:27, "John Benediktsson" :
> You can probably use a bunch of models that hold their state/location and the 
> UI renders them. Each thread can update the model's value when it changes?
>
> What kind of library were you thinking you needed?

  Oh, I dunno. Something someone developed for a simple 2d-game or a flash-like 
animation platform.

  Actually, I've no experience in these things, so I wanted to read something 
to get the idea how people conceptualize and approach such tasks.

  What I actually need is a way to model and visualize a bunch of robots and a 
conveyor line so I can develop a control strategy and work out some corner-case 
scenarios. I have a bunch of constraints, and I need to create an understanding 
of the way to command the robots for optimal conveyor throughput.

 In fact, I have a rough understanding of the control algorithm, I just wanted 
to see it in motion and work out the details. A rewindable timeline would be 
very helpful.

  Any ideas?

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

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

Re: [Factor-talk] Actors on Screen

2016-11-25 Thread John Benediktsson

You can probably use a bunch of models that hold their state/location and the 
UI renders them.  Each thread can update the model's value when it changes?

What kind of library were you thinking you needed?


> On Nov 25, 2016, at 10:14 AM, Alexander Ilin  wrote:
> 
> Hello!
> 
>  I'd like to have some visual objects moving around the screen with the given 
> speed and trajectory.
> 
>  It would be nice to have all objects be separate threads (active objects, as 
> they are sometimes known).
> 
>  Do we have a vocab to help with that?
> 
> ---=--- 
> Александр
> 
> --
> ___
> 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] Actors on Screen

2016-11-25 Thread Alexander Ilin

Hello!

  I'd like to have some visual objects moving around the screen with the given 
speed and trajectory.

  It would be nice to have all objects be separate threads (active objects, as 
they are sometimes known).

  Do we have a vocab to help with that?

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

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

Re: [Factor-talk] Libudis86.dll (Was: TYPED: Declarations)

2016-11-25 Thread Alexander Ilin

Thank you for the advice, Björn!

25.11.2016, 17:29, "Björn Lindqvist" :
> It is easiest if you put the builds online somewhere and open an issue
> referencing them. Then John and Doug can add them to the dll directory
> here: http://downloads.factorcode.org/dlls/ That the files you have
> built are smaller than the existing ones can be good or bad. I've
> found that it is often hard to control what dependencies VS will add
> to dlls you build. Sometimes it will decide to link to debug libraries
> and such. But you can check that with the excellent depends.exe
> utility: http://www.dependencywalker.com/

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

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

Re: [Factor-talk] Libudis86.dll (Was: TYPED: Declarations)

2016-11-25 Thread Björn Lindqvist

It is easiest if you put the builds online somewhere and open an issue
referencing them. Then John and Doug can add them to the dll directory
here: http://downloads.factorcode.org/dlls/ That the files you have
built are smaller than the existing ones can be good or bad. I've
found that it is often hard to control what dependencies VS will add
to dlls you build. Sometimes it will decide to link to debug libraries
and such. But you can check that with the excellent depends.exe
utility: http://www.dependencywalker.com/

2016-11-25 9:22 GMT+01:00 Alexander Ilin :
> Thank you, John, that was very helpful!
>
>> P.S., I think 32-bit libudis86.dll exists somewhere, and I know 32-bit
>> libudis86 is supported on other OS's.
>
> I have found the sources here: https://github.com/vmt/udis86
>
> I happen to have VS2010, so I managed to build both 64- and 32-bit versions
> of the DLL, v1.7.2. I can contribute those if you tell me the way.
> BTW, for some reason my 64-bit build DLL file is smaller than the one at
> http://downloads.factorcode.org/dlls/64/
> Maybe that's good.
>
> Anyway, when testing the thing under 32-bit I found an issue, of which I'm
> not sure whether it's ours or theirs:
>
> IN: scratchpad : test2+ ( n -- n )  2 + ;
> IN: scratchpad \ test2+ disassemble
> 083c2c10: a300106907mov [0x7691000], eax
> 083c2c15: 83c604add esi, 0x4
> 083c2c18: c7062000  mov dword [esi], 0x20 ! > This should be
> 0x02
> 083c2c1e: a300106907mov [0x7691000], eax
> 083c2c23: ba2d2c3c08mov edx, 0x83c2c2d (test + 0x1d)
> 083c2c28: e903465bffjmp 0x7977230 (+)
> 083c2c2d:   add [eax], al
> 083c2c2f:   add [eax], al
> 083c2c31:   add [eax], al
> 083c2c33:   add [eax], al
> 083c2c35:   add [eax], al
> 083c2c37:   add [eax], al
> 083c2c39:   add [eax], al
> 083c2c3b:   add [eax], al
> 083c2c3d:   add [eax], al
> 083c2c3f: 00invalid
>
> The same issue is present in the 64-bit build of the libudis86.dll
> downloaded from http://downloads.factorcode.org/dlls/64/
>
> It can also be reproduced using their command-line client:
>> echo a3 00 10 69 07 83 c6 04 c7 06 20 00 00 00 | udcli -x
>  a300106907   mov [0x7691000], eax
> 0005 83c604   add esi, 0x4
> 0008 c7062000 mov dword [esi], 0x20
> All three lines of the above output have half-bytes swapped in the mnemonics
> (0x20 instead of 0x2, 0x4 instead of 0x40, etc.).
>
> This begs the question: do we supply bad data to the disassembler, or does
> disassembler misinterprets what we give it?
>
> ---=---
> Александр
>
>
> --
>
> ___
> Factor-talk mailing list
> Factor-talk@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/factor-talk
>



-- 
mvh/best regards Björn Lindqvist

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

Re: [Factor-talk] Libudis86.dll (Was: TYPED: Declarations)

2016-11-25 Thread Jon Harper

All things in factor carry their type with them at runtime. For everything
but integers, this is done by manipulating pointers to the thing instead
and requiring an alignment of the address of the thing. This means that a
pointer to this thing will have its lower bits with a value of 0 (the
number of bits depends on the alignment. In factor, everything is aligned
to 16 bytes, so 4 bits are 0). This is not much of a cost because most
things (think tuples, arrays, etc) are bigger then 16 bytes, and you want
stuff to be aligned for performance anyway.
So since the lower bits always have a value of 0, you can actually put any
value in there an just ignore it when following the pointer.

For integers only, you don't manipulate pointers, you manipulate the value.
When you are doing operations on integers, you need to shift right to get
the value (and throw away the tag), do the operation, then shift left and
re add the tag. You then notice that if you choose the tag 0 for integers,
you don't have to re-add the tag because shifting left inserts zeroes. And
you also notice that "( (a >> 4) + (b >> 4)  ) << 4" is "a + b"  (except
when there is an overflow) because of the maths properties (distribution of
* to +). So for many operations on integers (like +), you can just do them
directly on the tagged (= shifted) integer.

Hopefully I didn't make too many mistakes in my explanation, anyone feel
free to correct me if I'm wrong :)

Jon

On Fri, Nov 25, 2016 at 12:24 PM, Alexander Ilin  wrote:

> Hi!
>
> I have no idea what integer tagging is, but it's great that there is no
> bug.
>
> To all: I still have the 32-bit buld of the DLL, which I'd like to make
> available on the Factor Downloads page.
>
> 25.11.2016, 11:57, "Jon Harper" :
>
> Hi,
> It's actually the correct data.
> All integers are shifted by 4 (hence the 28/60 discussions). The tag of
> integers was chosen to be 0 so that some operations (like +) dont' have to
> shift before and after. But some operations do have to shift their
> arguments to their actual values first.
>
> If you do : testshift ( n m -- k )  { fixnum fixnum } declare shift ;
> you'll see that the second argument is shifted before the shift
> instruction is called.
>
> Or
> : test2shift ( n -- n )  2 shift ;
> Should have the correct constant somwhere.
>
> Le 25 nov. 2016 09:23, "Alexander Ilin"  a écrit :
>
> Thank you, John, that was very helpful!
>
> > P.S., I think 32-bit libudis86.dll exists somewhere, and I know 32-bit
> libudis86 is supported on other OS's.
>
> I have found the sources here: https://github.com/vmt/udis86
>
> I happen to have VS2010, so I managed to build both 64- and 32-bit
> versions of the DLL, v1.7.2. I can contribute those if you tell me the way.
> BTW, for some reason my 64-bit build DLL file is smaller than the one at
> http://downloads.factorcode.org/dlls/64/
> Maybe that's good.
>
> Anyway, when testing the thing under 32-bit I found an issue, of which I'm
> not sure whether it's ours or theirs:
>
> IN: scratchpad : test2+ ( n -- n )  2 + ;
> IN: scratchpad \ test2+ disassemble
> 083c2c10: a300106907mov [0x7691000], eax
> 083c2c15: 83c604add esi, 0x4
> 083c2c18: c7062000  mov dword [esi], 0x20 ! > This should be
> 0x02
> 083c2c1e: a300106907mov [0x7691000], eax
> 083c2c23: ba2d2c3c08mov edx, 0x83c2c2d (test + 0x1d)
> 083c2c28: e903465bffjmp 0x7977230 (+)
> 083c2c2d:   add [eax], al
> 083c2c2f:   add [eax], al
> 083c2c31:   add [eax], al
> 083c2c33:   add [eax], al
> 083c2c35:   add [eax], al
> 083c2c37:   add [eax], al
> 083c2c39:   add [eax], al
> 083c2c3b:   add [eax], al
> 083c2c3d:   add [eax], al
> 083c2c3f: 00invalid
>
> The same issue is present in the 64-bit build of the libudis86.dll
> downloaded from http://downloads.factorcode.org/dlls/64/
>
> It can also be reproduced using their command-line client:
> > echo a3 00 10 69 07 83 c6 04 c7 06 20 00 00 00 | udcli -x
>  a300106907   mov [0x7691000], eax
> 0005 83c604   add esi, 0x4
> 0008 c7062000 mov dword [esi], 0x20
> All three lines of the above output have half-bytes swapped in the
> mnemonics (0x20 instead of 0x2, 0x4 instead of 0x40, etc.).
>
> This begs the question: do we supply bad data to the disassembler, or does
> disassembler misinterprets what we give it?
>
> ---=---
> Александр
>
>
> 
> --
>
> ___
> Factor-talk mailing list
> Factor-talk@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/factor-talk
>
>
> ,
>
> 
> --
> ,
>
> ___
> Factor-talk mailing list

Re: [Factor-talk] Libudis86.dll (Was: TYPED: Declarations)

2016-11-25 Thread Alexander Ilin

Hi! I have no idea what integer tagging is, but it's great that there is no bug. To all: I still have the 32-bit buld of the DLL, which I'd like to make available on the Factor Downloads page. 25.11.2016, 11:57, "Jon Harper" :Hi,It's actually the correct data.All integers are shifted by 4 (hence the 28/60 discussions). The tag of integers was chosen to be 0 so that some operations (like +) dont' have to shift before and after. But some operations do have to shift their arguments to their actual values first.If you do : testshift ( n m -- k )  { fixnum fixnum } declare shift ;you'll see that the second argument is shifted before the shift instruction is called.Or: test2shift ( n -- n )  2 shift ;Should have the correct constant somwhere. Le 25 nov. 2016 09:23, "Alexander Ilin"  a écrit :Thank you, John, that was very helpful! > P.S., I think 32-bit libudis86.dll exists somewhere, and I know 32-bit libudis86 is supported on other OS's. I have found the sources here: https://github.com/vmt/udis86 I happen to have VS2010, so I managed to build both 64- and 32-bit versions of the DLL, v1.7.2. I can contribute those if you tell me the way.BTW, for some reason my 64-bit build DLL file is smaller than the one at http://downloads.factorcode.org/dlls/64/Maybe that's good. Anyway, when testing the thing under 32-bit I found an issue, of which I'm not sure whether it's ours or theirs: IN: scratchpad : test2+ ( n -- n )  2 + ;IN: scratchpad \ test2+ disassemble083c2c10: a300106907    mov [0x7691000], eax083c2c15: 83c604    add esi, 0x4083c2c18: c7062000  mov dword [esi], 0x20 ! > This should be 0x02083c2c1e: a300106907    mov [0x7691000], eax083c2c23: ba2d2c3c08    mov edx, 0x83c2c2d (test + 0x1d)083c2c28: e903465bff    jmp 0x7977230 (+)083c2c2d:   add [eax], al083c2c2f:   add [eax], al083c2c31:   add [eax], al083c2c33:   add [eax], al083c2c35:   add [eax], al083c2c37:   add [eax], al083c2c39:   add [eax], al083c2c3b:   add [eax], al083c2c3d:   add [eax], al083c2c3f: 00    invalid The same issue is present in the 64-bit build of the libudis86.dll downloaded from http://downloads.factorcode.org/dlls/64/ It can also be reproduced using their command-line client:> echo a3 00 10 69 07 83 c6 04 c7 06 20 00 00 00 | udcli -x a300106907   mov [0x7691000], eax0005 83c604   add esi, 0x40008 c7062000 mov dword [esi], 0x20All three lines of the above output have half-bytes swapped in the mnemonics (0x20 instead of 0x2, 0x4 instead of 0x40, etc.). This begs the question: do we supply bad data to the disassembler, or does disassembler misinterprets what we give it? ---=---Александр --___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] Libudis86.dll (Was: TYPED: Declarations)

2016-11-25 Thread Jon Harper

Hi,
It's actually the correct data.
All integers are shifted by 4 (hence the 28/60 discussions). The tag of
integers was chosen to be 0 so that some operations (like +) dont' have to
shift before and after. But some operations do have to shift their
arguments to their actual values first.

If you do : testshift ( n m -- k )  { fixnum fixnum } declare shift ;
you'll see that the second argument is shifted before the shift instruction
is called.

Or
: test2shift ( n -- n )  2 shift ;
Should have the correct constant somwhere.

Le 25 nov. 2016 09:23, "Alexander Ilin"  a écrit :

Thank you, John, that was very helpful!

> P.S., I think 32-bit libudis86.dll exists somewhere, and I know 32-bit
libudis86 is supported on other OS's.

I have found the sources here: https://github.com/vmt/udis86

I happen to have VS2010, so I managed to build both 64- and 32-bit versions
of the DLL, v1.7.2. I can contribute those if you tell me the way.
BTW, for some reason my 64-bit build DLL file is smaller than the one at
http://downloads.factorcode.org/dlls/64/
Maybe that's good.

Anyway, when testing the thing under 32-bit I found an issue, of which I'm
not sure whether it's ours or theirs:

IN: scratchpad : test2+ ( n -- n )  2 + ;
IN: scratchpad \ test2+ disassemble
083c2c10: a300106907mov [0x7691000], eax
083c2c15: 83c604add esi, 0x4
083c2c18: c7062000  mov dword [esi], 0x20 ! > This should be
0x02
083c2c1e: a300106907mov [0x7691000], eax
083c2c23: ba2d2c3c08mov edx, 0x83c2c2d (test + 0x1d)
083c2c28: e903465bffjmp 0x7977230 (+)
083c2c2d:   add [eax], al
083c2c2f:   add [eax], al
083c2c31:   add [eax], al
083c2c33:   add [eax], al
083c2c35:   add [eax], al
083c2c37:   add [eax], al
083c2c39:   add [eax], al
083c2c3b:   add [eax], al
083c2c3d:   add [eax], al
083c2c3f: 00invalid

The same issue is present in the 64-bit build of the libudis86.dll
downloaded from http://downloads.factorcode.org/dlls/64/

It can also be reproduced using their command-line client:
> echo a3 00 10 69 07 83 c6 04 c7 06 20 00 00 00 | udcli -x
 a300106907   mov [0x7691000], eax
0005 83c604   add esi, 0x4
0008 c7062000 mov dword [esi], 0x20
All three lines of the above output have half-bytes swapped in the
mnemonics (0x20 instead of 0x2, 0x4 instead of 0x40, etc.).

This begs the question: do we supply bad data to the disassembler, or does
disassembler misinterprets what we give it?

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



--

___
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] Libudis86.dll (Was: TYPED: Declarations)

2016-11-25 Thread Alexander Ilin

Thank you, John, that was very helpful! > P.S., I think 32-bit libudis86.dll exists somewhere, and I know 32-bit libudis86 is supported on other OS's. I have found the sources here: https://github.com/vmt/udis86 I happen to have VS2010, so I managed to build both 64- and 32-bit versions of the DLL, v1.7.2. I can contribute those if you tell me the way.BTW, for some reason my 64-bit build DLL file is smaller than the one at http://downloads.factorcode.org/dlls/64/Maybe that's good. Anyway, when testing the thing under 32-bit I found an issue, of which I'm not sure whether it's ours or theirs: IN: scratchpad : test2+ ( n -- n )  2 + ;IN: scratchpad \ test2+ disassemble083c2c10: a300106907    mov [0x7691000], eax083c2c15: 83c604    add esi, 0x4083c2c18: c7062000  mov dword [esi], 0x20 ! > This should be 0x02083c2c1e: a300106907    mov [0x7691000], eax083c2c23: ba2d2c3c08    mov edx, 0x83c2c2d (test + 0x1d)083c2c28: e903465bff    jmp 0x7977230 (+)083c2c2d:   add [eax], al083c2c2f:   add [eax], al083c2c31:   add [eax], al083c2c33:   add [eax], al083c2c35:   add [eax], al083c2c37:   add [eax], al083c2c39:   add [eax], al083c2c3b:   add [eax], al083c2c3d:   add [eax], al083c2c3f: 00    invalid The same issue is present in the 64-bit build of the libudis86.dll downloaded from http://downloads.factorcode.org/dlls/64/ It can also be reproduced using their command-line client:> echo a3 00 10 69 07 83 c6 04 c7 06 20 00 00 00 | udcli -x a300106907   mov [0x7691000], eax0005 83c604   add esi, 0x40008 c7062000 mov dword [esi], 0x20All three lines of the above output have half-bytes swapped in the mnemonics (0x20 instead of 0x2, 0x4 instead of 0x40, etc.). This begs the question: do we supply bad data to the disassembler, or does disassembler misinterprets what we give it? ---=---Александр --
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk

Re: [Factor-talk] Actors on Screen

Re: [Factor-talk] Actors on Screen

Re: [Factor-talk] Actors on Screen

Re: [Factor-talk] Actors on Screen

[Factor-talk] Actors on Screen

Re: [Factor-talk] Libudis86.dll (Was: TYPED: Declarations)

Re: [Factor-talk] Libudis86.dll (Was: TYPED: Declarations)

Re: [Factor-talk] Libudis86.dll (Was: TYPED: Declarations)

Re: [Factor-talk] Libudis86.dll (Was: TYPED: Declarations)

Re: [Factor-talk] Libudis86.dll (Was: TYPED: Declarations)

Re: [Factor-talk] Libudis86.dll (Was: TYPED: Declarations)

11 matches

Site Navigation

Mail list logo

Footer information