On Sat, Oct 22, 2011 at 4:05 PM, Freddie Chopin wrote:
> The change that Steve Bennett suggested me in email is now posted to Gerrit
> and it solves the problem.
>
>> uplevel #0 [list source [find $filename]]
Great, hopefully this will get committed soon.
--
Xiaofan
___
The change that Steve Bennett suggested me in email is now posted to
Gerrit and it solves the problem.
> uplevel #0 [list source [find $filename]]
4\/3!!
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.d
> I have to agree with you here. Make things work first, nice to have but
> not essential things can come later.
It's a policy to reduce the # of unnecessary changes to OpenOCD. The #
of willy-nilly
changes in itself drives the quality down.
We don't understand this problem yet, so we're likely t
On Sat, Oct 22, 2011 at 1:52 AM, Freddie Chopin wrote:
> Why can't we revert a change, fixing a bug and wait for a real jimtcl-expert
> (Steve) to discuss other alternatives while in the meantime OpenOCD would
> work as expected for Windows users?
>
> "The problem" is that Windows paths now cannot
On 2011-10-21 19:39, Peter Stuge wrote:
Not so easy. I disagree with reverting the patch without having a
clear plan for the real fix.
Not easy because it is not neccessarily possible to implement the
same functionality in any other way.
The proper solution requries Jim expertise which I have n
Freddie Chopin wrote:
> Just as Peter suspected the problem is caused by commit
> a62d8f2271312ba955e839509590f5a5975b1b49. I've verified that with
> bisecting. I've also build version with that single commit reverted
> which worked as expected and as before.
Thanks for confirming that!
> I've
Just as Peter suspected the problem is caused by commit
a62d8f2271312ba955e839509590f5a5975b1b49. I've verified that with
bisecting. I've also build version with that single commit reverted
which worked as expected and as before.
I've pushed revert-patch for Gerrit review. I believe it should
Xiaofan Chen wrote:
> The following does work now.
> C:\work\openocd\binary>openocd -f board\\ek-lm3s1968.cfg
-f has not changed in almost 5 years, and directly calls the script
procedure, which was changed by Steve's commit.
So maybe both things are caused by the commit after all.
There's actua
On Fri, Oct 21, 2011 at 11:37 PM, Xiaofan Chen wrote:
> On Fri, Oct 21, 2011 at 11:06 PM, Peter Stuge wrote:
>> So there are two differences in behavior versus 0.5:
>>
>> 1. \ in -f parameters get evaluated one time extra by Jim tcl
>> 2. paths in -f parameters are now relative to a different dir
On Fri, Oct 21, 2011 at 11:06 PM, Peter Stuge wrote:
> So there are two differences in behavior versus 0.5:
>
> 1. \ in -f parameters get evaluated one time extra by Jim tcl
> 2. paths in -f parameters are now relative to a different directory,
> one level down from previously
>
> 2. is most lik
Peter Stuge wrote:
> > C:\work\openocd\binary\bin>openocd.exe -f board//ek-lm3s1968.cfg
> > Open On-Chip Debugger 0.6.0-dev-snapshot (2011-10-21-21:26)
> > Licensed under GNU GPL v2
> > For bug reports, read
> > http://openocd.sourceforge.net/doc/doxygen/bugs.html
> > Runtime Error: embedde
Xiaofan Chen wrote:
> For version 0.5.0, the following two commands work and I use only
> either of them.
> openocd.exe -f board\ek-lm3s1968.cfg
> openocd.exe -f board/ek-lm3s1968.cfg
>
> For latest git, none of the following commands work.
> openocd.exe -f board\ek-lm3s1968.cfg
> openocd.exe -f b
On Fri, Oct 21, 2011 at 7:06 PM, Spencer Oliver wrote:
> On 20 October 2011 17:04, Freddie Chopin wrote:
>> The only working version that I've found is:
>>> openocd -f ../interface/jtagkey.cfg -f ../target/stm32.cfg
>>
>
> i cannot reproduce this problem, any more details.
>
I can reproduce the
W dniu 2011-10-21 13:50:26 użytkownik Spencer Oliver
napisał:
> you could either do a git bisect to see what version it broke at.
Will bisecting also affect jimtcl version used as a submodule or maybe always
the most recent one is used?
Generally I see some changes that could affect path handl
On 21 October 2011 12:40, freddie_chopin wrote:
> W dniu 2011-10-21 13:06:05 użytkownik Spencer Oliver
> napisał:
>> i cannot reproduce this problem, any more details.
>
> We'll... I've compiled master from yesterday, using the same tools and
> libraries (libusb and libftdi) as before, using th
W dniu 2011-10-21 13:06:05 użytkownik Spencer Oliver
napisał:
> i cannot reproduce this problem, any more details.
We'll... I've compiled master from yesterday, using the same tools and
libraries (libusb and libftdi) as before, using the same script as before -
generally nothing changed from m
On 20 October 2011 17:04, Freddie Chopin wrote:
> Hi!
>
> The most recent OpenOCD behaves differently on Windows than 0.5.0 (and
> before) and in my opinion the direction of change is to worse.
>
> OpenOCD 0.5.0 could be run this way:
>> openocd -f interface/jtagkey.cfg -f target/stm32.cfg
> And i
W dniu 2011-10-21 00:12:52 użytkownik Andrew Leech
napisał:
> Have you tried with double backslash "\\" ?
Actually no, I guess that it would probably work but you'd still have to give
path to OpenOCD working directory in Eclipse and probably still use "..\\"
before directory with config file.
On 21/10/2011 3:04 AM, Freddie Chopin wrote:
1. In 0.5.0 you could use slash or backslash (which is more "correct"
in Windows) - no difference. Now only slash works, backslash is
ommited and replaced with... nothing...
2. When running OpenOCD as External Tool from Eclipse I always left
"Working
Hi!
The most recent OpenOCD behaves differently on Windows than 0.5.0 (and
before) and in my opinion the direction of change is to worse.
OpenOCD 0.5.0 could be run this way:
> openocd -f interface/jtagkey.cfg -f target/stm32.cfg
And it worked fine. Current OpenOCD when trying this gives:
> Ru
20 matches
Mail list logo
