Gerald Combs wrote:
> An alternative to keeping it hidden would be to add a default menu item
> with the text "Why is this menu empty?", or "How to add items to this
> menu", which takes the user to a help page describing how to add items.
>
Don't you think this is a very poor mans solution - in
Bill Meier wrote:
> So: another option is just to stay with Bash v3.1-6 until the situation
> further resolves itself.
>
I've looked at some of the discussion in the cygwin mailing lists and
I'm impressed of the ignorance some cygwin developers take care about
the problems that virtually thou
An alternative to keeping it hidden would be to add a default menu item
with the text "Why is this menu empty?", or "How to add items to this
menu", which takes the user to a help page describing how to add items.
LEGO wrote:
> The menu is there just when compiled with Lua, and the current
> init.
>
>
> It turns out that there's a fair amount of discussion on the Cygwin mailing
> list about changes made in Cygwin Bash handling of \r\n in script files in
> versions after v 3.1-6 to improve Cygwin Bash performance.
>
> See http://cygwin.com/ml/cygwin/2006-10/msg00079.html for the latest
Daniel Griscom wrote:
> Self-interest is a great motivator of open-source projects.
>
Yes, for sure. Unfortunately important things such as documentation that
are not that interesting often falls down the edge :-(
However, I notice that things are getting better at a lot of open source
projec
On Sun, Oct 15, 2006 at 12:32:48PM +0530, [EMAIL PROTECTED] wrote:
> While going through the README.developer file , I was trying to
> understand the tree concept but could not grasp much . Can anyone
> please provide some inputs to help me understand how the tree nodes
> are added and display
On Sun, 2006-10-15 at 20:10 +0200, Joerg Mayer wrote:
> 00 00 00 04 00 00 00 01 00 00 00 01 00 00 00 00
> ^^^
> What do these bytes mean? ---|
>
> 0010 0d 20 .
yes
On 10/15/06, Joerg Mayer <[EMAIL PROTECTED]> wrote:
> When looking at the dissector, I wondered whether the following patch
> would be ok/appropriate:
>
> Index: epan/dissectors/packet-usb.c
> ===
> --- epan/dissectors/packet-usb.
The last four bytes of the header represents the number of setup bytes present.
If it is 0 it is not displayed.
Maybe we whould change this so that the setup length is always displayed?
There was a very recent fix for libpcap that solves the offset-by-one
error for the data stored in each packet
Hello Paolo,
Frame 1 (18 bytes on wire, 18 bytes captured)
Arrival Time: Jan 1, 1970 01:35:47.483647000
[Time delta from previous packet: 0.0 seconds]
[Time since reference or first frame: 0.0 seconds]
Frame Number: 1
Packet Length: 18 bytes
Capture Length:
Hi
,
While going through
the README.developer file , I was trying to understand the tree concept but
could not grasp much .
Can anyone please
provide some inputs to help me understand how the tree nodes are added and
display tree gets built .
Regards
,
Vikash
The information containe
When looking at the dissector, I wondered whether the following patch
would be ok/appropriate:
Index: epan/dissectors/packet-usb.c
===
--- epan/dissectors/packet-usb.c (revision 19541)
+++ epan/dissectors/packet-usb.c (wor
ronnie sahlberg wrote:
> USB packets probably arrive at such very slow rate anyway that a few
> gettimeofday() calls are unlikely to cause any performance issues.
>
Sure? Think of a fully saturated 100MBit Ethernet adapter connected to
the USB port.
I'll guess that could really cause some perf
On 10/15/06, Paolo Abeni <[EMAIL PROTECTED]> wrote:
> Hello,
>
> On Sat, 2006-10-14 at 21:42 +, ronnie sahlberg wrote:
> > In the example capture unplug_mouse2.cap
> > it appears that the timestamp for the packet is not generated properly.
> > All packets show up as JAN 1 1970.
> >
> > 1, Can y
Hello,
On Sat, 2006-10-14 at 21:42 +, ronnie sahlberg wrote:
> In the example capture unplug_mouse2.cap
> it appears that the timestamp for the packet is not generated properly.
> All packets show up as JAN 1 1970.
>
> 1, Can you have a look at the timestamp generation of packets when capturi
Paolo.
Could you have a look at the USB memory stick network trace that is
present on http://wiki.wireshark.org/SampleCaptures?
When I look at these traces it looks to me there is something wrong
with the captured data.
The USB header is fine, as is the SETUP data but the actual data
blob l
16 matches
Mail list logo