Hi Ron,
Thank you for your message.
I apologize that I was not answering for such long time.
Now I'm extremely busy with adopting my programs to SAF-T in Poland:
https://www.pwc.ch/news/en/26707/poland-introduce-standard-audit-file-tax-saf-t-1-july-2016
http://www.internationaltaxreview.co
Hi my vote is also Yes. This Will make better future sinc of both projects
Regards
Luiz
Em 29/04/2016 21:17, "Ron Pinkas" escreveu:
> Dear Przemek,
>
> My sincere thanks, for your kind and generous email and suggestions.
>
> I personally agree with practically all of your observations and
> sug
>>>Hi my vote is also Yes. This Will make better future sinc of both projects
+1...
Regards.
--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance i
Hi my vote is also Yes. This Will make better future sinc of both projects
Regards
Luiz
Mostrar texto das mensagens anteriores
Mostrar texto das mensagens anteriores
https://lists.sourceforge.net/lists/listinfo/xharbour-developers
-
Dear Przemek,
My sincere thanks, for your kind and generous email and suggestions.
I personally agree with practically all of your observations and suggestions,
with just few reservations.
1. GLOBAL scope ( which is also directly accessible by C code).
2. Name spaces.
3. I never believed that
Il 27/04/2016 11:09, Patrick Mast ha scritto:
> Enrico, we can do this in a different branche, so we still have current code
> to work with as "stable", and new branch as "non stable" until that one gets
> stable.
>
> I'm all in favour of winning speed.
Ok.
EMG
--
EMAG Software Homepage: ht
Hello,
> So my final question is:
> Are you interesting in taking current Harbour code and adding
> xHarbour extensions which were not ported to Harbour core code
> and you think are important just to keep base code for both
> compilers as close as possible. In practice it would mean also
> that w
Il 27/04/2016 00:22, Przemyslaw Czerpak ha scritto:
> I can help in this process but only if other xHarbour developers
> agree with this idea and can help at least reporting differences.
I personally don't agree. Current xHarbour is rock solid for me and I
don't want to take the risk and suppo
Hi Ron,
Sorry for late response. I'm very busy recently.
Because my message below I address to all xHarbour developers
I'm setting CC to xHarbour devel list.
I do not think it's worth to port single modifications from
Harbour to xHarbour. Just simply it's full time job for many
months. There are
Hi Ron and Walter.
The problem can be exploited by many different
syntax errors.
When syntax error appears we cannot trust that
our expression destructor is executed because
we do not know where exactly the error was
detected by bison and if all sub expressions
created so far have internal binding
Hi, Ron
I'm fine, many responsability, working with xHarbour.
Adding debug to parser I have this sequence:
*** New Macro: >>>(file_alias = $1)<<< Len: 17
Starting parse
Entering state 0
Reading a token:
Reducing Delimiter: '(' As: 40
Passing through: 40
Returning: 40
Next token is token '(' ()
Hey Walter, :-)
(How are you?)
How much memory, and what is stored int it?
We need to follow the EXPRESSION TREE, and find which element is not released.
It should be a Parenthesized Exp, which has a single element, being an EQUATION
where the left side is the IDENTIFIER file_alias, and the ri
Thanks for the relay.
IMO, it should be OK now.
--
Andi
On Mon, 11 Jan 2010 12:22:23 +0200
Ella Stern wrote:
> According to bugreport 449:
>
> After execution sample below fm.log reports:
> Memory Allocation Report
> Application: E:\test.exe
> xHarbour Version: xHarbour build 1.2.1 Intl. (Sim
13 matches
Mail list logo
