Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [henshin-dev] Bug when using Attribute Conditions

Hi Manuel,

no worries -- it's great that you're trying to fix this bug.

The sort test works now, but the bank-map test / example doesn't.You can find it in the examples plugin. I've not looked into it yet.

Cheers,
Christian


2014-07-05 14:31 GMT+02:00 Manuel Hegner (HPI) <manuel.hegner@xxxxxxxxxxxxxxxxxxxxxxxxxx>:
I am sorry. My regular _expression_ accidentely required variable names with at least two characters. Because of that the sort test failed (having the variables x, y, i and j). Here is the fixed patch.


Am 05.07.2014 13:54, schrieb Christian Krause:
Hi Manuel,

thanks for the investigation and the patch. This part is indeed not really clean.

I am having trouble running the sort-test with your change (see also http://www.ckrause.org/2013/05/henshin-098-working-with-lists.html). Some how it seems not to terminate. Could you maybe check what is going on there?

Cheers,
Christian


2014-07-04 17:17 GMT+02:00 Manuel Hegner (HPI) <manuel.hegner@xxxxxxxxxxxxxxxxxxxxxxxxxx>:
Hey,

First thanks for creating this cool tool. It's a lot of fun working with it. I found a bug while working with it though. Sometimes if you use Attribute Conditions that use the modulo operation (%) the interpreter fails with the exception that one of the attributes is unknwon.

After some research I found the problem in org.eclipse.emf.henshin.interpreter.info.ConditionInfo. There the condition is parsed and the code tries to extract all the used parameters. I guess this is so that the conditions can be executed as early as possible to prevent unused matching. The problem is that the method extractParameter is not splitting the string correctly. It is only splitting on some special characters not '%'. So when the js expressiong variable%10==0; is parsed it results in the token variable%10 which is not matching any of the defined parameters (variable % 10 == 0; works though).

To prevent this from happening it would be better to use a regular _expression_:
[$_\\p{Lu}\\p{Ll}\\p{Lt}\\p{Lm}\\p{Lo}\\p{Nl}][$_\\p{Lu}\\p{Ll}\\p{Lt}\\p{Lm}\\p{Lo}\\p{Nl}\\p{Mn}\\p{Mc}\\p{Nd}\\p{Pc}]+ (http://mathiasbynens.be/notes/_javascript_-identifiers)

This should match most possible _javascript_ variable names (it does not consider U+200C zero width non-joiner characters, U+200D zero width joiner characters).

Here is the patch I would like to contribute to fix the bug.

Best regards,
Manuel Hegner

_______________________________________________
henshin-dev mailing list
henshin-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/henshin-dev



_______________________________________________
henshin-dev mailing list
henshin-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/henshin-dev


_______________________________________________
henshin-dev mailing list
henshin-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/henshin-dev


Back to the top