Compiler resolves the module path the wrong way

[AlienCoder]

Hello to all,

the following phenomenon seems to be a banal on the first look. But it isn't:

The compiler does not resolve the path of a module correctly any more:

tryThisOut.packageLevel02.packageLevel03.DeeplyRootedClass.useMeWithTheFullPath();

This went through the compiler for several times without any trouble. But now an error is thrown:

      src/Main.hx:319: characters 8-33 : tryThisOut.TryOut has no field packageLevel02      

The compiler assumes that  tryThisOut.TryOut is addressed. This class exists. But it is not addressed at this place (not even in the lines before or after this line).


This is  a test code to test implementations with function calls that are not addressed by the 'import' keyword.
I am experimenting with macros and I also want to cover this specific case.

But the same error occurs when I let the original source code be compiled without the influence of macros

I am desperate. I was looking for the error for about two hours...

Kind regards
Michael

[Dan Korostelev]

Hey. I'm sorry, but I couldn't understand. Could you provide a reproducible example in a new Github issue?

среда, 20 июля 2016 г., 17:36:30 UTC+3 пользователь AlienCoder написал:

[AlienCoder]

Hello Dan,

thank you for taking care of my problem.

First of all, I have to confess something:

This account ( alienCoder ) is for posting my "stupid questions". I have finished my education as an IT-Specialist For Software Development last year. I am also very sophisticated with the semantic/ logic understanding of programming and also "the rest of the world". But there are still some open spaces in the haxe syntax for me.

So, I did not want to start to present cool concepts and clever source code on the one hand and to ask "rookie questions" on the other hand.

My true name is Arnim and I am working on a IDE-independent graphical debugger. I am sorry for any confusing this might have caused.

Here is the github source code of the strange occurance.

Actually I did not want to pose this question under my true name, as it might seem, that I do not have the controle over my own source code. I was intensely looking for the error on my side. But I did not find any.

Kind regards
Arnim

[Dan Korostelev]

I cloned that repo, removed the external dependencies from the hxml file and it did compile fine for me. So I assume it's something wrong in your macros, so I think we'll need a minimal but completely reproducible example.

четверг, 21 июля 2016 г., 13:49:16 UTC+3 пользователь AlienCoder написал:

[AlienCoder]

Thank you for the information. Then this must be a technical issue laying on my side.

I am sorry for the wrong .hxml file with the dependencies still in them...
Any how the right one wasn't commited in the first run.

The issue also occurs on my side without the dependencies bound in.

Critical is the line 319:

tryThisOut.packageLevel02.packageLevel03.DeeplyRootedClass.useMeWithTheFullPath();

The compiler suddenly assumes that I wanted to execute   tryThisOut.TryOut.packageLevel02   which of cause does not exist. There have been several compilations that have been absolutely clean. When I have changed code at a different place, this issue occured.

Thank you for efforts. Then I will have to check my configurations and technical set-ups. I recently updated HAXE and my hxcpp. Maybe I have done something wrong here...

May I ask you, what version of HAXE and of hxcpp do you use?

[Maximiliano Fernández]

Hi.

As I see you're trying to call a public method as a class public static method. The correct form has to be instancing the class and then call the method. Perhaps that's making all the trouble? Or am I wrong?

Cheers

Maximiliano Fernández

--
To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en
---
You received this message because you are subscribed to the Google Groups "Haxe" group.
For more options, visit https://groups.google.com/d/optout.

[AlienCoder]

Hello Maximiliano,

thank you for the hint. Yes, that would be a problem if the compiler would resolve the classpath correctly. But it doesn't.

It's odd. As this phenomenon only occurs in the main()... And the function calls with the full classpath can be swapped arbitrarily. The result is always the same.

The first package seems to be escaped to a class name. Then the rest of the class path is considered to be a class field of this class.

When I copy this function call into another method ( that calls this fullclasspath-method ) the function calls works well.

As it only occurs on my side, there must be a technical issue. And this one is obviously not so easy to identify. I will have a look at other occurrances in future. For now, I am afraid that I would bind the precious time of other community members with no realistic chance of quick answers.

So, I have closed the thread.

Thank you both for your efforts. I believe, the long term will deliver a solution.

Kind regards