I am communicating with Kamil about the possibility of sharing code
between the two plugins. We plan to have a common base class for the
shared functionality between the OSs. I have asked Kamil to perform
this experiment, so we can identify which parts of the code can be
shared in the first place.
On 15.12.2016 14:14, Pavel Labath wrote:
> I am communicating with Kamil about the possibility of sharing code
> between the two plugins. We plan to have a common base class for the
> shared functionality between the OSs. I have asked Kamil to perform
> this experiment, so we can identify which par
On 15 December 2016 at 14:14, Kamil Rytarowski wrote:
> On 15.12.2016 14:14, Pavel Labath wrote:
2. PTRACE_SETSIGINFO - equivalent currently unsupported, I will need to
add support for it in ptrace(2).
>> This value is currently only used in logging code, so we can just
>> remove it
Just to let you know, I will be on vacation until the end of the year,
so probably will not respond to any comments until January. If you
have any concerns, do let me know, as I'd like to get started when I
get back.
pl
On 13 December 2016 at 16:32, Pavel Labath wrote:
> Hello again,
>
> I'd to
On 15.12.2016 16:08, Pavel Labath wrote:
> On 15 December 2016 at 14:14, Kamil Rytarowski wrote:
>> On 15.12.2016 14:14, Pavel Labath wrote:
>
> 2. PTRACE_SETSIGINFO - equivalent currently unsupported, I will need to
> add support for it in ptrace(2).
>>> This value is currently only u
So, I want to delete the testcases symlink from the LLDB tree, and move the
tests out of the packages directory into tests/testcases.
A few reasons why I want to do this:
(1) I can't imagine symlinks in SVN is something that works well on platforms
that don't support symlinks (like Windows)
(2)
The reason they were put into the packages directory in the first place is
because this forms a proper python package so that more code can be shared
amongst test cases. I don't know why the symlink was ever created in the
first place, sounds like that was probably put in place by someone who
thou
Yes, writing that long path every time you run a test case was indeed the
reason for that symlink. I stood it for a couple of weeks before it drove me
round the bend! You want it to be a real path and not just have the test suite
accept partial paths because it is really handy to use the shell
It's definitely possible to (at worst) shorten the path if we say we don't
care about supporting other languages (i'm fine saying that for now unless
someone comes along with a serious committment to support and maintaining
other bindings). So we could drop packages/Python for example.
I also rem
Hi Pavel, sorry for not keeping up with the thread, I've been super busy all
this week. I'm not going to object to where this proposal has ended up. I
personally have a preference for the old system but not based on any
justifiable reasons.
> On Dec 15, 2016, at 7:13 AM, Pavel Labath wrote:
10 matches
Mail list logo
