ping? [RFC] [icedtea-web] reproducer for handling spaces

Omair Majid omajid at redhat.com
Fri Nov 4 07:31:00 PDT 2011


On 11/03/2011 04:44 PM, Jiri Vanek wrote:
> On 11/03/2011 09:26 PM, Omair Majid wrote:
>> On 11/03/2011 04:16 PM, Jiri Vanek wrote:
>>> On 11/03/2011 08:05 PM, Omair Majid wrote:
>>>> On 11/03/2011 02:33 PM, Jiri Vanek wrote:
>>>>> On 11/03/2011 05:35 PM, Omair Majid wrote:
>>>>>> On 11/01/2011 12:52 PM, Jiri Vanek wrote:
>>>>>>> Hi! This is reproducer for recently fixed PR804 and for new PR811
>>>>>>> (based
>>>>>>> on Behaviour of javaws when handling spaces).
>>>>>>> Currently all local-files requests test are passing (804) ( just
>>>>>>> one of
>>>>>>> them was passing before 804 patch) and all remote (811) requests are
>>>>>>> falling.
>>>>>>> Some minor changes were necessary to engine. The reproducer itself
>>>>>>> will
>>>>>>> not work without this chnages.
>>>>>>>
>>>>>>
>>>>>> Perhaps we should extract scripts that prepare reproducers from the
>>>>>> makefile so we wont need to source NEW_LINE_IFS. What do you think?
>>>>>
>>>>> On one side I'm not sure how better will be to source extracted
>>>>> scripts
>>>>> which prepare reproducers. On the other side, I'm not sure what to
>>>>> imagine under "extract them". I imagine separate bash script....
>>>>> What do
>>>>> you yourselves mean?
>>>>>
>>>>
>>>> Yes, I meant bash scripts. Sorry if this was not very clear.
>>>>
>>>> I am thinking of something (roughly) like this:
>>>> ./jnlp-reproducers --compile
>>>> ./jnlp-reproducers --test-all
>>>> ./jnlp-reproducers --test simple 'Spaces can be everywhere.jnlp'
>>>
>>> Then I imagined the same:) but I do not think it is good idea:( At the
>>> end number of exported makefile variables can be to large.
>>>
>>
>> Oh, fair enough.
>>
>>>>
>>>> Then again, I am not sure if it is really a good idea - especially the
>>>> bit that moves compiling instructions away from the makefile. But I
>>>> think it's an excellent opportunity to sneak in my idea about easily
>>>> being able to run a single test from the command line ;)
>>> But to your second "sneaking" :o) question - what exactly do you want
>>> (me) to improve?. Currently, i can comfortably run/debug each reproducer
>>> from his testsuite inside IDE (one by one or all in one ). And I can
>>> also easily verify the behaviour by running prepared reproducer from
>>> some virtual server with just compiled javaws(or again debug inisde
>>> IDE). What else can you want!:)
>>
>> Oh, that's very cool! I was trying to debug a reproducer once and
>> couldn't figure out how to do this. Would you mind explaining how you
>> do this?
>
> I will write this tomorrow or during weekend ok? (Will need my full
> attention, now I'm getting sleepy :) )
>

Of course, please take your time. No need to hurry :)

> Just one more clarification. I can debug reproducer XOR debug netx. I
> was not successful to debug it together. Enough?
>>

That should be fine, I think.

>>> Because it is so easy to run single reproducer from IDE, then i believe
>>> that the only problem to run it from commandline is correct setting of
>>> classpath.
>>>>
>>>> As for restoring IFS, you can do simple assignments in the makefile to
>>>> restore IFS:
>>>
>>> Actually, you can't. I do not know why, but inside mkefile, the IFS
>>> variable is different from shell (just space in my case, whether in
>>> shell contains space,\t and \n). If I'm changing it in "shell", then I
>>> prefer to restore it by the same way. The line you wrote, was my exactly
>>> first idea:)
>>>
>>
>> Well if IFS has a different value when running under make, how is that
>> a problem? As long as you set it back to the old IFS, I would expect
>> things to work fine.
>
> Ok. Unless it cause some catastrophe I will do this as you suggested.
>

Please let us know how it goes.

Cheers,
Omair




More information about the distro-pkg-dev mailing list