James, I remember going through some similar motions as you are. Looks like
you are searching for a form of indexing your record fields.
So many good suggestions, I had to join the fray and try something... My
preferred approach would also be an ordinal type for the axes and a
record variant, as al
e able to hide them most of the time but show them if trying to debug
> without re-compiling.
>
>
>
> James
>
>
>
> *From:* fpc-pascal *On Behalf
> Of *Stefan V. Pantazi
> *Sent:* Thursday, August 29, 2019 1:11 PM
> *To:* FPC-Pascal users discussions
> *
I would chalk this up to differences between OS versions, configurations,
devices, etc and move on. I see all memory is released. At least it does
not crash and burn badly.
The function call you want to play with is:
libusb_set_debug
http://libusb.sourceforge.net/api-1.0/group__lib.html#ga5f8376b
libusb has a debug verbosity level which currently is set to 3 (i.e., very
verbose) in the device open function.
There is a define in libusbx.pas that you can change to shut off debug
messages.
On Thu, Aug 29, 2019 at 12:03 PM James Richters <
ja...@productionautomation.net> wrote:
> Now I have
oop as
if I get a -7, I don't need to bother checking the data at all since it was not
read, it was just a timeout. https://github.com/Zaaphod/libusbxhid/tree/Test
James
-Original Message-----
From: fpc-pascal On Behalf Of Stefan
V. Pantazi
Sent: Tuesday, August 27, 2019 10:35 PM
Yeah you are right, Windows was less forgiving. Sorry about that and
thank you Jean.
For simple data structures written only from one thread, using critical
section may be overkill. But if your data structure is a queue or a
longer buffer, with length, etc. that is being produced by one thread
I agree with you: the libusbhid_interrupt_read and
libusb_interrupt_transfer are very close semantically and returning as a
result either the length of transferred data or the error code would
make a lot of sense. But in rare cases one may still need to check both
parameters:
http://libusb.so
l
It it easy to add the calls to libusbx but they need to be tested that
they actually work as expected.
Any ideas?
James
-Original Message-
From: fpc-pascal On Behalf Of Stefan
V. Pantazi
Sent: Friday, August 23, 2019 10:54 AM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-p
Thanks for pushing on this. I think any pending timeout/transfer must be
explicitly canceled before closing the USB device, so that the thread
can end gracefully.
The only way I see is to use something like
libusb_handle_events_timeout_completed
http://libusb.sourceforge.net/api-1.0/group__
I suspect when the timeout time has been reached interrupt_read is calling
libusb_cancel_transfer to stop waiting for the transfer. It seems likely that
what's happening is that once in a while it tries to cancel the transfer, but
before libusb_cancel_transfer has a chance to cancel it, so
I added libusbhid_test_with_thread.pp to github. In that test you will
notice I also attempted to test sharing across threads a data structure
with (hypothetical) pen positions, using critical sections. Seems to
work ok, but more testing is needed to make sure there are no problems.
The way I
On 8/21/19 6:35 PM, James Richters wrote:
I had them separated, but whenever it happened that I tried to write while it
was waiting to read, I would get the error below. If it was reading all the
time it seemed fine.. just if it was idle waiting to read and I did a write
that it would fail w
From your example it looks like you placed the device reading
(interrupt read) and writing (set report) into the same read thread. I
thought keeping them separate was a good idea: tight loop reads and
less frequent writes (LCD updates).
Libusb is supposed to be thread-safe. Not really an issu
On 8/21/19 8:30 AM, James Richters wrote:
I FINALLY wrote some data to the LCD!! YAY !!! I was trying to get the python application to work.. without any luck.. but I ended up going ahead and trying Zadig changing the driver to
Persistence pays off. Congrats!
Also I need to stick a $06
My guess is that it would be better to leave the time sensitive read
thread to do the fast reads and immediate calculations and leave writing
to the device screen in a separate thread (even main thread), with a
lower update frequency!
Yes, that was what I was attempting to describe.. but I can't
On 8/18/19 3:58 PM, James Richters wrote:
As far as reading it goes, things are going pretty well.. I still have yet to write to
the display.. I can't get any of my attempts to send data to it to be successful at all..
I get "control transfer to usb device failed!"
Assuming there are no othe
James,
From the looks of it you made good progress reading the hardware and
using a dedicated thread for it. Congrats! Seems you're in the thick of
it now ready to get the minute details sorted out.
Anyway, just a heads up that concurrent programming (threads,
synchronization, etc) has many
Is the segfault in the same place or has it changed?
To debug further, you have to compare sizes of data structures, field
types and function call parameter types between the libusb 1.0 and the
old libusb0.1. - any mismatch could result in a segfault.
On 8/17/19 3:51 PM, James Richters wrote
ow to get
stdcall to properly work with pas-libusb.
James
-Original Message-----
From: fpc-pascal On Behalf Of Stefan
V. Pantazi
Sent: Saturday, August 17, 2019 12:11 PM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] USB Human Interface Devices
Libusb can be compiled with e
8/17/19 11:46 AM, Jean SUZINEAU wrote:
Le 17/08/2019 à 17:10, Stefan V. Pantazi a écrit :
The obvious first thing to make sure is that the calling convention
matches the library for the platform. I see that in
https://github.com/Zaaphod/pas-libusb/blob/Hack/src/libusb.pas 9line 46)
the ca
The obvious first thing to make sure is that the calling convention
matches the library for the platform. I see that in
https://github.com/Zaaphod/pas-libusb/blob/Hack/src/libusb.pas 9line 46)
the calling convention on Windows is cdecl (the stdcall is commented
out). In libusbxhid, if I remember
On 8/16/19 11:11 AM, James Richters wrote:
Remember that interrupt reads are blocking so the way to deal with them is to
put them away from the main thread, in their own thread. The moment something
is available from the device, then the main thread of your application is
signaled to read a
On 8/16/19 6:23 AM, James Richters wrote:
DATA!!
Is there a way I can read data from the device with a timeout instead of just
waiting forever for it? It doesn't send anything unless I push a button, but I
need to do other things like update the LCD if I am not pushing a button.
something simpler just
to get SOMETHNG to work so I can figure out what's supposed to even be
happening.
James
-Original Message-
From: fpc-pascal On Behalf Of Stefan
V. Pantazi
Sent: Thursday, August 15, 2019 5:31 PM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] USB
Hi James,
I remember going through many similar difficulties with HID. A few years
ago I was trying to connect to much simpler devices than yours (game
controllers, weather station base, graphic tablet, etc). USB programming
is confusing and many abstraction layers have been created aiming at
Haev a look at rtti and the functionality available in the typinfo unit.
The tests included in fpc are a good resource. Have a look at the
trtti*.pp tests:
https://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/tests/test/
Start with trtti4.pp and work your way up to more complex examples.
On 7
:
Thank you, using fgl; did work.
Am I correct in assuming that if I want other types of Variables I would change
PWord in
specialize TFPGMap;
to something else, maybe PString, PDouble, PLongint etc?
James
-Original Message-
From: fpc-pascal On Behalf Of Stefan
V. Pantazi
Sent
You can use the TFPGMap class in fgl unit to implement the dictionary.
fgl should be available in 3.0.4. Try to replace the
Generics.Collections with fgl and the type definition in the example
code from zh loza. The rest should be identical.
[...]
uses fgl;
type
TVariableDictionary = specia
Read down the first page, the section "Objects - Dynamic Variables" -
all will become clear.
By avoiding the virtual methods, you can keep your objects static, all
stored on stack, no need for constructors. I personally find very useful
for my projects.
Find fixed example below. Hope it help
I had a similar problem when trying to represent trees using extended ASCII
characters. My solution was to adapt my character representations to UTF8.
To see what I mean you can have a look at
https://github.com/svpantazi/catalan-monoid-generator. The
generate_catalan_monoid.pp contains a PrintASCI
tefan V. Pantazi a écrit :
That is quite the case statement you have there. You may benefit
greatly from re-analyzing and refactoring your programs by splitting
them in multiple individual units, if possible. That should be
perfectly possible if Dosomething();DoSomethingelse(); keep
repe
That is quite the case statement you have there. You may benefit greatly
from re-analyzing and refactoring your programs by splitting them in
multiple individual units, if possible. That should be perfectly
possible if Dosomething(); DoSomethingelse(); keep repeating across your
70+ switch case
add ptcwrapper to uses list.
I get reopengraph.pas(32,23) Error: Identifier not found "TPTCWrapperThread"
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
On 06/26/2017 10:21 AM, James Richters wrote:
Is there a way to re-scale a drawing with agg_2D?
I think so, scaling is one of the transformations that agg supports
well. The way I would go about this would be to study how agg manages
the parsing, storage and display of svg drawings, which ar
Thank you for this, Michael. I think it is wonderful work.
I've done some old tests of the new implementation and it looks very
good. The only failed tests were related to date and time
representation. This appears to be fixed in the new version. Most
importantly, I see no memory leaks when pa
When in doubt, have a look at the source code of the graphical
primitives to determine the semantics of each one. Unlike line primitive
which draws a path immediately, lineto is meant to be used multiple
times, as part of a draw path. So, lineto does not really draw, it just
adds a vertex to a
I think I figured it out. It hink ptcgraph was not designed with that
functionality in mind. If you take a look at the ptcgraph unit, it has
initialization and finalization sections where the ptc wrapper object is
created and freed. That happens only at application start and finish not
during r
On Linux 64bit, reopening of a second window works fine, as expected. On
Windows it does not, and behaves as you reported. This is most likely
related to the use of a separate thread (TPTCWrapperThread) in ptcgraph.
As far as I know graph and wincrt do not use threads. I suspect that on
windows
Good find and great sleuth work.
It is possible that the original reason for switching R and B channels
was to make the agg color object more compatible with LCL which seems to
prefer BGR, order, but who knows... One obvious problem seems to be
function AggToLCLColor(const c: TAggColor): TCol
I was waiting for the right time to also offer my sincere thanks to all
teams and individual contributors. I have been using fpc and Lazarus IDE
for quite some years now and I am very pleased with the constant
progress and improvement of these development tools. I have enjoyed
reading and learn
I think you need to use a global define passing a -d??? parameter
(-dAGG2D_USE_FREETYPE) to the compiler. Just adding it to a unit only
defines for that unit and to any file included in that one unit.
On 06/14/2017 09:40 PM, James Richters wrote:
The font rendering should all be controlled by
Yes, it is puzzling. Different pointer sizes, compilers, OS, 32/64 bit
library dependencies, can be potential causes.
Again, note that I compiled the example on a CentOS 7, 64bit Linux with
Lazarus 1.5 + fpc 3.0.1
I can also confirm that the test program compiles and works fine on
Ubuntu 16.
While in lazarus open agg_rasterizer_scanline_aa.pas, go ro line 611
press Ctr and click on ptrcomp. It should open agg_basics.pas, the
comment may apply to your situation.
It is unclear to me whether you are on a win32 or win64 OS? If you are
already on a win64 machine then your default targe
Looks like it may be something specific to your setup. In my tests I
used Lazarus 1.5 as IDE and fpc 3.0.1 on Linux. Crosscompiled example
ran on Win7 64 bit. So there are already differences with your
environment. Noting your problems with compilation, you may want to
consider using Lazarus ID
There is a minus sign in the call:
agg^.attach(@graph_buffer.data, IMAGE_WIDTH, IMAGE_HEIGHT,
-(IMAGE_WIDTH * RGB_WIDTH))
Removing it will flip the Y axis.
With regard to color, there may be two options:
1) the ideal way would be to specify the rgb order of a pixel format in
the Agg_2D con
-boun...@lists.freepascal.org] On Behalf Of
Graeme Geldenhuys
Sent: Monday, June 05, 2017 2:25 PM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] Implementing AggPas with PtcGraph
On 2017-06-05 03:12, Stefan V. Pantazi wrote:
In my experience, the one dependency that AggPas has potenti
I will need to do
on my target installations where freepascal will not be installed.
Any ideas on what causes this error and advice on how to install what is
needed on client (non-development) systems?
James
-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org]
worked fine, except for one
48 bytes memory leak reported by heaptrc and that I left unfixed.
Stefan
On 06/03/2017 03:37 PM, Graeme Geldenhuys wrote:
On 2017-06-03 17:45, Stefan V. Pantazi wrote:
Also, for the example
to work, the agg object constructor must be modified as well, I included
all
On 06/03/2017 06:52 AM, Graeme Geldenhuys wrote:
On 2017-06-03 01:56, Stefan V. Pantazi wrote:
http://pascal.net.ru/PutImage+(en)
[...]
"BitMap is an untyped parameter that contains the height and width of
the region, and the bit image that will be put onto the screen."
[...]
Coul
o actually do a
getimage() at some point to set the shape of before putimage will work.. I'll
do some experiments with it.
James
-Original Message-
From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of
Stefan V. Pantazi
Sent: Thursday, June 01, 2017 9:47 AM
I literally just sent a reply with the solution. I had to guess the
width and height were longints. Your message confirmed it. I attached an
updated version of the test program, the old one had a few typos.
Thank you for your work on the ptcpas, I found it very useful for my
projects.
On 06/
Have a look at the agg_2D unit. The agg_2D uses
..
agg_pixfmt ,
agg_pixfmt_rgba ,
..
Therefore, the rgba format is pretty much baked in. That is to say that
the constructor of the main object Agg2D uses the pixfmt_rgba32 to set
the pixel format.
...
{ CONSTRUCT }
constructor Agg2D.Construct
52 matches
Mail list logo
