Il 24/12/2011 08:59, Alexandre Julliard ha scritto:
Massimo Del Fedele writes:
So, the question : have I understood right from changelogs and text is completed
in DIB engine, so I can help to make it a bit faster, or it's still missing
something so I should just wait ?
Text is done.
Massimo Del Fedele writes:
> So, the question : have I understood right from changelogs and text is
> completed
> in DIB engine, so I can help to make it a bit faster, or it's still missing
> something so I should just wait ?
Text is done. Most likely Autocad is using som
As I've got no idea of the status of DIB engine, besides looking at changelogs,
I'd like to know it... at least to see if there's some need of help.
The stuff that interests me at most is, as usual, the display speed of
autocad with embedded truetype fonts (aka bug 13801), which de
Hi,
Amazing I'm a long time follower of the project and to see a DIB engine
implemented is a huge milestone given all the trials and tribulations
leading up to it. Honestly never thought it would happen everyone needs
to give themselves a pat on the back today :-)
Regards,
Keith
Il 25/07/2011 10:20, Huw Davies ha scritto:
On Sun, Jul 24, 2011 at 07:10:46PM +0300, Octavian Voicu wrote:
Disclaimer: these comments are based only on what I gather from
following commits and looking at the code, so can't guarantee it's
100% accurate; Huw or Alexandre would know better.
This
On Sun, Jul 24, 2011 at 07:10:46PM +0300, Octavian Voicu wrote:
> Disclaimer: these comments are based only on what I gather from
> following commits and looking at the code, so can't guarantee it's
> 100% accurate; Huw or Alexandre would know better.
This is a good summary of where we're at - nic
Il 24/07/2011 19:32, James McKenzie ha scritto:
On 7/24/11 10:14 AM, Massimo Del Fedele wrote:
Yep, true Autocad would gain benefit just with fonts. If fonts are not
implemented, that's useless by now.
Max:
It might be worthwhile to rebase your code on the fixes inputted by Huw so that
y
On 7/24/11 10:14 AM, Massimo Del Fedele wrote:
Yep, true Autocad would gain benefit just with fonts. If fonts are
not
implemented, that's useless by now.
Max:
It might be worthwhile to rebase your code on the fixes inputted by Huw
so that your patches continue to work until Huw finishes
Yep, true Autocad would gain benefit just with fonts. If fonts are not
implemented, that's useless by now.
Thank you for your answer waiting for better times, so :-)
Max
On Sun, Jul 24, 2011 at 4:11 PM, Massimo Del Fedele wrote:
> Having seen many patches related to DIB engine lately, I built latest
> sources and tried it No speed enhancements on AutoCAD, my test app.
> So, I wonder if the engine is already working, at least partially, or not.
Having seen many patches related to DIB engine lately, I built latest
sources and tried it No speed enhancements on AutoCAD, my test app.
So, I wonder if the engine is already working, at least partially, or not.
If yes, there's some switch/environment variable to enable it ?
Sorr
To the list as well.
Original Message
Subject:Re: DIB engine
Date: Mon, 01 Jun 2009 19:09:15 -0700
From: James McKenzie
To: Andrew Eikum
References:
<1243755935.4535.1.ca...@stephan-desktop>
<4a22ad55.5020...@brightnightgames.com>
&l
On Sun, 2009-05-31 at 12:23 -0700, Dan Kegel wrote:
> On Sun, May 31, 2009 at 12:45 AM, Stephan Rose wrote:
> >> If you're looking for something better specified, try finishing off
> >> gdiplus.
> > ... I'll check into gdiplus missing bits sometime next week. :)
> >
> > My name's Andrew Eikum, I'm
On Sun, May 31, 2009 at 12:45 AM, Stephan Rose wrote:
>> If you're looking for something better specified, try finishing off
>> gdiplus.
> ... I'll check into gdiplus missing bits sometime next week. :)
>
> My name's Andrew Eikum, I'm an undergraduate Computer
> Science student at the University o
On Sun, May 31, 2009 at 2:11 PM, Andrew Eikum
wrote:
> I am definitely doing small commits and following the WineGit wiki page.
> One concern I have is that the number of patches will probably be over 50
> or even 75 -- I'm not sure if it'd be better to submit them all in one go as
> they're pret
Austin English wrote:
On Sun, May 31, 2009 at 11:16 AM, Andrew wrote:
My name's Andrew Eikum, I'm an undergraduate Computer Science student at the
University of Minnesota. I contacted a Wine dev a few weeks ago asking for
a small project to use to get familiar with Wine. I was pointed towa
On Sun, May 31, 2009 at 11:16 AM, Andrew wrote:
> My name's Andrew Eikum, I'm an undergraduate Computer Science student at the
> University of Minnesota. I contacted a Wine dev a few weeks ago asking for
> a small project to use to get familiar with Wine. I was pointed towards the
> gdiplus sect
Stephan Rose wrote:
On Sat, 2009-05-30 at 14:14 -0700, Dan Kegel wrote:
Stephan Rose wrote:
My ears perked up when the two words DIB and spec were put
together in the same sentence. One frustration I encountered
when wanting to contribute to wine a little over two years ago
was that nob
On Sat, 2009-05-30 at 14:14 -0700, Dan Kegel wrote:
> Stephan Rose wrote:
> > My ears perked up when the two words DIB and spec were put
> > together in the same sentence. One frustration I encountered
> > when wanting to contribute to wine a little over two years ago
> > was that nobody seemed to
2009/5/30 Dan Kegel :
> If you're looking for something better specified, try finishing off
> gdiplus. That's a somewhat well defined graphics package,
> and Wine's implementation has a few missing bits yet, last
> I checked.
OH YES PLEASE.
(lots of apps missing bits of this - check over bugz
Stephan Rose wrote:
> My ears perked up when the two words DIB and spec were put
> together in the same sentence. One frustration I encountered
> when wanting to contribute to wine a little over two years ago
> was that nobody seemed to be able to say "Hey, this is what
> we are missing/need, here
reference?
This was also raised on the existing thread. No. This is a problem.
The best we have so far is "DIB engine should be integrated into
GDI32". This is not a problem, because both Max and AJ share this
goal, but if I understand correctly, Max doesn't want to invest the
effort
"Stephan Rose" wrote:
So if anyone can drop a full spec into my lap which outlines everything
I need to write and where (given I adhere to things as I should of course)
I won't have any issues getting that accepted later on, I'd be more than
willing to take on something like this.
Anyone need
do hacks, hence AJ's reluctance to include the current
DIB proposal in Wine (to make it "correct" later will require a lot of
hacking, as Max has objected).
> Do we even have an architectural document or guidelines to reference?
This was also raised on the existing thread. No. This
d is not
> acceptable as far as code style, fashion and what he expects out of the
> development efforts for the DIB engine. Making a statement
> after months of work is IHMO very unacceptable.
>
> Also, I don't see this as circular, but the 'snake' of getting
t. Without this, any further work would be futile and could end up
>being very frustrating. I've seen this from Huw and it is starting to come
>from Max. AJ needs to get some time together and write up what is and is not
>acceptable as far as code style, fashion and what he expect
James Mckenzie ha scritto:
Luke:
Heh, I wonder if someone should approach Autodesk and say, "Give us
sponsorship and we'll get Autocad running on Linux" they surely have
deep pockets :)
If Autodesk were interested in making AutoCad work with Linux, they would make
a native version, not try to
Luke:
>
>Heh, I wonder if someone should approach Autodesk and say, "Give us
>sponsorship and we'll get Autocad running on Linux" they surely have
>deep pockets :)
>
If Autodesk were interested in making AutoCad work with Linux, they would make
a native version, not try to get it working with Wine
be futile and could end up
being very frustrating. I've seen this from Huw and it is starting to come
from Max. AJ needs to get some time together and write up what is and is not
acceptable as far as code style, fashion and what he expects out of the
development efforts for the DIB en
2009/5/29 Austin English :
> On Fri, May 29, 2009 at 10:50 AM, chris ahrendt wrote:
>> Right Austin,
>> I have... thats why I asked the question why not sit down and say
>> here is what we want from the DIB engine here is the Spec do this ..
>> I have seen the her
On Fri, May 29, 2009 at 10:50 AM, chris ahrendt wrote:
> Right Austin,
> I have... thats why I asked the question why not sit down and say
> here is what we want from the DIB engine here is the Spec do this ..
> I have seen the here is what I don't like. But nothing showing
l document or guidelines to reference?
>>
> If you read the entire thread, you'll see that the DIB design is not a
> puzzle that can be carved out and dropped in. The DIB engine must be
> designed from scratch. Designing the DIB architecture is half of the
> work itself, si
design is not a
puzzle that can be carved out and dropped in. The DIB engine must be
designed from scratch. Designing the DIB architecture is half of the
work itself, since that involves planning a lot of the code/testing,
etc.
He pointed out a few things he didn't like about Massimo's desig
Question on this debate:
Has AJ documented anywhere what the architectural issues are so they can
be addressed?
I have not seen this in the thread and was just wondering.
If we have them documented then its a relatively easy task to address
each of them.
Yes it may be a hack but you would be su
e "intermediary step" in
> the master tree (there could be many reasons for this).
> As you said, starting the move to gdi32 right now would be a huge
> waste of time (in maintenance and more), and prone to hell-knows how
> many regressions. You should get the DIB engine uploaded
this).
As you said, starting the move to gdi32 right now would be a huge
waste of time (in maintenance and more), and prone to hell-knows how
many regressions. You should get the DIB engine uploaded to its own
repo or wine-hacks (http://repo.or.cz/w/wine/hacks.git).
It's also been mentioned,
On Thu, May 28, 2009 at 2:20 PM, Massimo Del Fedele wrote:
> IMHO, and really "in my opinion", loosing time to integrate it inside gdi32
> whithout proper guidelines would be crazy. I mean, I'd never do it :-)
> The intermediate step was made (among other reasons) to check if the
> upcoming driver
HI Ben,
Ben Klein ha scritto:
Of course, it also makes it more difficult to maintain, with any
change in gdi32 needing to be mirrored in the forked DIB engine, but
that's where git cherry-picking can come in handy :)
Done for about 3 monthes, no more time for it :-)
What I was tryi
with any
change in gdi32 needing to be mirrored in the forked DIB engine, but
that's where git cherry-picking can come in handy :)
> 2) My engine insertrs itself between gdi32 and the display driver; I begins
> to be tired repeating that it's a step through the final design on wh
aviour of every Windows control inside and out, just that this is
an area I feel capable of working on.
I am in awe of what the DirectX developers have done. I doubt I would
be able to work in that area. Especially as I don't understand either
DirectX or OpenGL. Same goes for the GDI/DIB en
On Wed, May 27, 2009 at 8:47 PM, James McKenzie
wrote:
> So what say all, shall we try to make coding better and as Max stated,
> fun. Most of the folks here do not support this project for a living
> and we should not restrict this project to those who do. However, it
> appears that a vast majo
Massimo Del Fedele wrote:
> Alexandre Julliard ha scritto:
>>
>> The last time I rejected a simple patch from Massimo, he basically said
>> that he didn't have time to fix the patch and just dropped it. That
>> doesn't encourage me to spend more effort on reviewing his more complex
>> stuff.
>>
>
>
ution
> > * description of Your solution incl. proposed integration plan
> >
>
> I have asked Alexandre about it but it wasn't really an option. Even
> for Huw writing a full dib engine (if he resumed his current code)
> would take five months or so full time. Fillin
serve as a solid base for further discussion about
> DIB integration requirements.
>
> Regards
> Hark
>
>
>
I have asked Alexandre about it but it wasn't really an option. Even
for Huw writing a full dib engine (if he resumed his current code)
would take five months or so full time.
Massimo Del Fedele wrote:
Btw, sorry all but I begins to be tired of telling same stuffs again and
again. I made a proposal for something that *could* help the migration to
final design, a *working* proposal, not just a prototype, and I believe
on it.
If that's not what most devels think, for m
On Wed, May 27, 2009 at 2:11 AM, Massimo Del Fedele wrote:
> Strange enough, as the consensus on Huw's design was great, and it used
> a *real* external driver, and *not* an intermediate one as mine.
> But I start thinking that the requirements and consensus are very fluid and
> moving matters, la
Ben Klein ha scritto:
A little while ago I was trying to run an app that uses Win16 DIB.DRV
(I forget which app it was). My research indicated that although
DIB.DRV was an actual driver (similar in architecture to Max's
proposed DIB engine) in Win16 systems, in Windows 95 the functionalit
any other device driver). Make that
as an analogy: GDI font - DIB, device font - DDB. Adding support for GDI
fonts didn't require introducing any new "font driver", so adding a DIB
engine shouldn't add a new one as well. DIB engine should be a GDI32 pure
internal thing.
I beg
s such a thing as device
> fonts (suported by x11drv, psdrv or any other device driver). Make that
> as an analogy: GDI font - DIB, device font - DDB. Adding support for GDI
> fonts didn't require introducing any new "font driver", so adding a DIB
> engine shouldn't add
e that
as an analogy: GDI font - DIB, device font - DDB. Adding support for GDI
fonts didn't require introducing any new "font driver", so adding a DIB
engine shouldn't add a new one as well. DIB engine should be a GDI32 pure
internal thing.
--
Dmitry.
On Monday 25 May 2009 15:03:17 Alexandre Julliard wrote:
> Writing a DIB engine is not a fill-in-the-blanks exercise. A large part
> of the task is precisely to come up with a good design,
Does anyone have a mention about what a good design should be?
My mention is that DIB driver shou
Alexandre Julliard ha scritto:
The last time I rejected a simple patch from Massimo, he basically said
that he didn't have time to fix the patch and just dropped it. That
doesn't encourage me to spend more effort on reviewing his more complex
stuff.
Hi again :-)
Well, to be precise those wer
t a thought. I think that maintaining a mirrored DDB copy
would slow down just a bit drawing operations but would speed up a lot blitting.
But it's not a need.
But even if you
do this that should be a purely internal x11drv decision, the DIB engine
shouldn't have any notion about
Chris Morgan writes:
> Wouldn't a review of the proposed dib engine be useful? One that
> included concerns, things that needed to be changed etc? Everyone
> involved seems to be asking for leadership and guidance about how to
> proceed, wouldn't a thorough review of th
s can be used with any driver (and with
multiple drivers at the same time). This is also why you can't have the
DIB driver decide on when to forward/not forward to the X11 driver, it
should go in the other direction.
I'm also very skeptical about mirroring DIBs with a DDB. But even
On Mon, May 25, 2009 at 9:32 PM, Chris Morgan wrote:
> On Mon, May 25, 2009 at 10:49 AM, Alexandre Julliard
> wrote:
>> Zachary Goldberg writes:
>>
>>> On Mon, May 25, 2009 at 7:03 AM, Alexandre Julliard
>>> wrote:
>>>>
>>>> Writin
On Mon, May 25, 2009 at 10:49 AM, Alexandre Julliard
wrote:
> Zachary Goldberg writes:
>
>> On Mon, May 25, 2009 at 7:03 AM, Alexandre Julliard
>> wrote:
>>>
>>> Writing a DIB engine is not a fill-in-the-blanks exercise. A large part
>>> of the ta
7;t cover these? If so, would
> you be able/willing to add some tests to the test suite?
>
Paul:
Max knows about the problems and the tests. He just does not have the
time right now to fix the problems and write the tests. He has hinted
and asked others to help him. I have no knowledge of
Alexandre Julliard ha scritto:
Well, the prototype doesn't show much evidence of a good design. Maybe
Massimo has one in mind, but he hasn't explained it so far.
Well, I still think that the "goodness" of a design is a matter of taste.
My design is *a* design, started because of a personal ne
Zachary Goldberg writes:
> On Mon, May 25, 2009 at 7:03 AM, Alexandre Julliard
> wrote:
>>
>> Writing a DIB engine is not a fill-in-the-blanks exercise. A large part
>> of the task is precisely to come up with a good design, validate it with
>> a prototype,
>
&
On Mon, May 25, 2009 at 7:03 AM, Alexandre Julliard wrote:
>
> Writing a DIB engine is not a fill-in-the-blanks exercise. A large part
> of the task is precisely to come up with a good design, validate it with
> a prototype,
Would you, Alexandre, say we are at this point? I.e. th
Jan de Mooij writes:
> On Sun, May 24, 2009 at 12:04 PM, Chris Howe wrote:
>> 2009/5/24 Massimo Del Fedele
>>
>> Sorry to sound like a stuck record but the Wine website still lists
>> "write a DIB engine" as a requirement, and every time someone
>&
Massimo Del Fedele wrote:
The engine has still some known bugs (known by me :-) ) which are not
spotter
by wine testsuite, mostly related to coordinate spaces in xxxBlt functions.
Are they not spotted because the tests don't cover these? If so, would
you be able/willing to add some tests to t
On Sun, May 24, 2009 at 12:04 PM, Chris Howe wrote:
> 2009/5/24 Massimo Del Fedele
>
> Sorry to sound like a stuck record but the Wine website still lists
> "write a DIB engine" as a requirement, and every time someone
> does, the patches dissapear down a hole bec
Notice how the word support and deployment overlap with the dib engine
and how the lines alternate color? The speed difference for editing is
like night and day. The header and footers for the document body
containing images renders fine. Installers such as ie6setup and msxml3
embedded imag
ort and deployment overlap with the dib engine
and how the lines alternate color? The speed difference for editing is
like night and day. The header and footers for the document body
containing images renders fine. Installers such as ie6setup and msxml3
embedded images don't render properly, I&
Steven Edwards wrote:
> On Sun, May 24, 2009 at 9:23 PM, James McKenzie
> wrote:
>
>> Let me know how this goes. I'm interested in improvements that will
>> help all *nixes, including MacOSX.
>>
>
> I think I am using the latest patch, its dibeng_max.zip thats got the
> 1-10 patches.
>
>
Steven Edwards wrote:
> On Sun, May 24, 2009 at 11:06 AM, Massimo Del Fedele wrote:
>
>> André Hentschel ha scritto:
>> No idea on what will happen with Mac or other unixes
>>
>
> I am attempting a Mac build now. As with the rest of the discussion,
> It would be nice if we could produc
On Sun, May 24, 2009 at 11:06 AM, Massimo Del Fedele wrote:
> André Hentschel ha scritto:
> No idea on what will happen with Mac or other unixes
I am attempting a Mac build now. As with the rest of the discussion,
It would be nice if we could produce a PE version using something like
cygwin w
2009/5/25 Massimo Del Fedele :
> André Hentschel ha scritto:
>>
>> I dont know anything about that, but may it be possible to compile your
>> code to a standalone driver for seperate download?
>> It would be great to just install a DIB-Driver for wine.
>> Sorry if that was a stupid idea.
>>
> The i
André Hentschel ha scritto:
Massimo Del Fedele schrieb:
André Hentschel ha scritto:
I dont know anything about that, but may it be possible to compile
your code to a standalone driver for seperate download?
It would be great to just install a DIB-Driver for wine.
Sorry if that was a stupid ide
Massimo Del Fedele schrieb:
André Hentschel ha scritto:
I dont know anything about that, but may it be possible to compile
your code to a standalone driver for seperate download?
It would be great to just install a DIB-Driver for wine.
Sorry if that was a stupid idea.
The idea is not stupid a
André Hentschel ha scritto:
I dont know anything about that, but may it be possible to compile your
code to a standalone driver for seperate download?
It would be great to just install a DIB-Driver for wine.
Sorry if that was a stupid idea.
The idea is not stupid at all :-)
I was thinking to d
I dont know anything about that, but may it be possible to compile your code to
a standalone driver for seperate download?
It would be great to just install a DIB-Driver for wine.
Sorry if that was a stupid idea.
Nope, and I think they will not be solved soon. Not by me, anyways.
I made my en
ion, ever.
>
I assume all this took place on IRC because unless I missed it,
Alexandre hasn't deigned to comment on here about what the
right architectural solution would be.
Sorry to sound like a stuck record but the Wine website still lists
"write a DIB engine" as a require
Kai Blin ha scritto:
On Sunday 24 May 2009 06:54:10 Ben Klein wrote:
Does that mean it's time to remove these todos (and make them full
tests) or are they still wanted for the case where Max's DIB engine is
not installed?
They are full tests, they're just marked as not passing
43fb8439a33a686512935597d4c43c19733/wine_ae-ub904-dib/gdi32:bitmap.html
too bad that the suite marks them as failures :-)
Does that mean it's time to remove these todos (and make them full
tests) or are they still wanted for the case where Max's DIB engine is
not installed?
I gues
On Sunday 24 May 2009 06:54:10 Ben Klein wrote:
> Does that mean it's time to remove these todos (and make them full
> tests) or are they still wanted for the case where Max's DIB engine is
> not installed?
They are full tests, they're just marked as not passing in win
checked out just the bitmap suite.
> It's trivial to fix, will do on next release
>
>> Yep, several todo's are passing now:
>>
>> http://test.winehq.org/data/b175a43fb8439a33a686512935597d4c43c19733/wine_ae-ub904-dib/gdi32:bitmap.html
>>
> too bad that the
di32:bitmap.html
too bad that the suite marks them as failures :-)
Full report:
http://test.winehq.org/data/b175a43fb8439a33a686512935597d4c43c19733/wine_ae-ub904-dib/report.html
(The user32 failure can be ignored, I get that spuriously without DIB engine).
Thank you for report.
I still h
The user32 failure can be ignored, I get that spuriously without DIB engine).
--
-Austin
I posted on bug 421 page (as usual) latest update of my engine.
It suld pass all tests in wine suite also all bitmap's todo_wines,
so expect some "false positive" signaled by tests.
Austin, could you please re-run it on your test machines ?
Ciao
Max
27;t want to use it
also, it's a real pity that git am doesn't accept stgit
patches 8-/ but anyway, that's off topic).
well, never used git-am, but I feel quite comfortable with stgit... also
because it make easy to correct or integrate a commit
An application that you might
w, the 9th patch in your series
is missing the 0009- prefix although the 'series' file claims it
should have; also, it's a real pity that git am doesn't accept stgit
patches 8-/ but anyway, that's off topic).
An application that you might want to test your DIB engine again
Well, it seems that the engine fixes some unrelated bugs too :-)
Bugs 15146 and 10408, as reported by a tester.
BTW In a couple of weeks all (few) remaining failing tests should be fixed.
Then I'll try to optimize somehow the mixed blitting, which is the only
stuff that remains slower than origin
Am Montag, den 18.05.2009, 13:41 +0200 schrieb Massimo Del Fedele:
> > Be careful with such statements. Look at bug 6519 for example.
> Yep, I've seen the bug :-)
> Anyways, most failures are fixed by now, also for monochrome bitmaps.
> Did you test it on bug's 6519 app ?
No, I don't really care.
Michael Karcher ha scritto:
Am Sonntag, den 17.05.2009, 17:35 +0200 schrieb Massimo Del Fedele:
1) Some color on monochrome bitmaps here I guess nobody knows how to do it
right. I fixed some todo wine (most) but have 2 failures which wine does right.
Seldom used anyways, and happens only on
Austin English ha scritto:
On Sun, May 17, 2009 at 10:35 AM, Massimo Del Fedele wrote:
Austin, could you please retest it against test suite ?
I've ran it, but it doesn't appear to be showing up on
test.winehq.org. I'll investigate why when I get a bit more time.
P.S., there's now a crash in
Am Sonntag, den 17.05.2009, 17:35 +0200 schrieb Massimo Del Fedele:
> 1) Some color on monochrome bitmaps here I guess nobody knows how to do
> it right. I fixed some todo wine (most) but have 2 failures which wine does
> right.
> Seldom used anyways, and happens only on weird palettes. I gue
On Sun, May 17, 2009 at 10:35 AM, Massimo Del Fedele wrote:
> Austin, could you please retest it against test suite ?
I've ran it, but it doesn't appear to be showing up on
test.winehq.org. I'll investigate why when I get a bit more time.
P.S., there's now a crash in user32/cursoricon.
--
-Aus
rmance test for these missing/buggy features, since you're aware of
them. That might help everyone, and also make your DIB engine more
attractive since it'll be passing even more tests that current Wine may
not be.
Keep up the good work :)
Thanks,
Scott Ritchie
Remaining bugs are related to :
1) Some color on monochrome bitmaps here I guess nobody knows how to do it
right. I fixed some todo wine (most) but have 2 failures which wine does right.
Seldom used anyways, and happens only on weird palettes. I guess not ever
Microsoft knows what they did
Zachary Goldberg ha scritto:
On Thu, May 14, 2009 at 5:01 AM, Massimo Del Fedele wrote:
Giuseppe Bilotta ha scritto:
On Thursday 14 May 2009 02:02, Massimo Del Fedele wrote:
I started fixing failures against test suite.
Most of bitmap ones are fixed, remaining are due
to still stubbed funcs.
On Thu, May 14, 2009 at 5:01 AM, Massimo Del Fedele wrote:
> Giuseppe Bilotta ha scritto:
>>
>> On Thursday 14 May 2009 02:02, Massimo Del Fedele wrote:
>>
>>> I started fixing failures against test suite.
>>> Most of bitmap ones are fixed, remaining are due
>>> to still stubbed funcs.
>>>
>>> Now
Giuseppe Bilotta ha scritto:
On Thursday 14 May 2009 02:02, Massimo Del Fedele wrote:
I started fixing failures against test suite.
Most of bitmap ones are fixed, remaining are due
to still stubbed funcs.
Now the problem is that it fixed also most todo_wines on bitmap suite
As usual, on b
On Thursday 14 May 2009 02:02, Massimo Del Fedele wrote:
> I started fixing failures against test suite.
> Most of bitmap ones are fixed, remaining are due
> to still stubbed funcs.
>
> Now the problem is that it fixed also most todo_wines on bitmap suite
>
> As usual, on bug 421 page for wh
I started fixing failures against test suite.
Most of bitmap ones are fixed, remaining are due
to still stubbed funcs.
Now the problem is that it fixed also most todo_wines on bitmap suite
As usual, on bug 421 page for who wants to test it.
Ciao
Max
ething so close to core
>>>>>> Wine functionality.
>>>>>>
>>>>>>
>>>>> Distributions don't really "support" Wine anyway. At best we just make
>>>>> a
>>>>> new package every now and again
eople should use git for filing bugs, but not
everyone does.)
We already expect our users to indicate if they've done any manual registry
changes when reporting bugs. This seems like just another instance of that.
But they usually don't.
As the Debian package maintainer, I won&#x
again.
>>>
>> Yes, but the point is that bugs filed against such a package are
>> potentially invalid. (People should use git for filing bugs, but not
>> everyone does.)
>>
>>
>
> We already expect our users to indicate if they've done any manual regis
1 - 100 of 321 matches
Mail list logo
