looking for mature/efficient gui builder/toolkit/IDE for Python (or C for that matter)
I'm interested in doing some graphical serial-port parsing software in Python (or possibly C which I'm actually more familiar with) - anyone care to render an opinion on the most direct route to a usable gui? I figure Python is probably somewhat the preferred language these days for GUIs given the large number of 'nix desktop apps that have been showing up in python of late... Last time I wrote a gui was in VisualC 6.0, so it's been awhile - with VisualC it took about the same amount of time to write all the coordinates for a GUI in the code as it did to draw it and hook up the code; hopefully things have gotten a bit more streamlined - hoping to spend most of my coding time on string parsing, not gui building... Thanks, Steve ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: thoughts on sorting files into sub-folders by access date?
RW,
Thanks! For posterity, this is the full script that works for me for
sorting my photos by date:
#!/bin/sh
for file in *.jpg *.jpeg *.JPG *.JPEG *.avi *.AVI
do
dir="${targetdir}`stat -f %Sm -t %Y.%m.%d ${file}`"
[ -d "${dir}" ] || mkdir "${dir}"
mv "${file}" "${dir}"
done
Best,
Steve
On Thu, Jul 1, 2010 at 5:38 PM, RW wrote:
> On Thu, 1 Jul 2010 22:08:55 +0100
> RW wrote:
>
>
>> dir="${targetdir}/`stat -f %Sm -t %Y%m%d ${file}`/"
>> [ -d "${dir}"] || mkdir "${dir}"
>> mv "${file}" "${dir}"]
>>
>
> Should be:
>
> dir="${targetdir}/`stat -f %Sm -t %Y%m%d ${file}`/"
> [ -d "${dir}" ] || mkdir "${dir}"
> mv "${file}" "${dir}"
> ___
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
>
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
thoughts on sorting files into sub-folders by access date?
Hi y'all, My high-end point&shoot camera likes to glob all my photos in a single folder, and it's glutting up my drive, and makes finding a specific trip unpleasant, with no good place for metadata. My SLR sorts them into folders by date, which I love. I can't find anything close googling, so I d/l a bunch of perl examples. Before I figure this out in python (I'm a hardware developer by trade, so that seems most sensible [libc doesn't seem to have any os-agnostic way of playing with file times, no?])... I thought I'd check if there's some trivially simple way of doing this with bash & find first. And, no, I'm kind of a keyboard jockey, so I'm not even considering importing all my photos into some app for handing my metadata. Text files do that just fine if I can sort them into folders. Best, Steve ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: there is a way to avoid strict libraries linking?
> It's much safer to just leave the libraries alone. Just because you > upgraded libpng doesn't mean that your old gtk binary will stop working > (assuming you are using "portupgrade" or "portmaster -w" which preserves old Untrue. Portupgrade deletes the old version of the port by default. The PNG upgrade was a major PITA, because I installed one new port that thought it had to have it. I'm sure 98% of the ports I then had to upgrade would have still worked just fine even if rebuilt against the old libpng. I think the complaint here is that the port dependencies system frequently gives the impression/enforces the rule that new ports will depend on whatever the most current version of everything is in the ports tree at the time they were built, forcing sort of a perpetual upgrade cycle. IMHO this is probably due to naive port maintainers (such as myself) incorrectly pointing a port at libpng.5 instead of any libpng, or libpng >= 5. Once the ports tree is 'poisoned' in this fashion, there's really no going back. I'd sure vote for an audit of this behavior as a summer of code project. Long story short, anything that sounds fundamental gets bumped (png, jpeg, tcl, python, gtk, etc, etc), I just sit back and get ready to spend two or three days retrying portupgrade -akOf -mBATCH=yes until everything sticks. If you've got OO or KDE4 installed, you might just want to forget it and pkg_delete -f *, then start over. I'm sticking by bsd though. You don't even have the opportunity to run an automated tool to clean & build everything from source automatically on linux. I'm sure rpm & apt dependencies are even nastier. Steve ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: flash drive crashes hald on amd64
Right there with you on this one. My solution was to get rid of hal :) Steve ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: includes, configure, /usr/lib vs. /usr/local/lib, and linux coders
That's alot of good info. It should go in the porter's handbook, maybe... So, if I'm looking to make a port, which one of those people should I be acting as? Maintainer? That's FreeBSD-port-terminology you are using, correct? Steve On Sat, Nov 1, 2008 at 8:55 AM, Giorgos Keramidas <[EMAIL PROTECTED]> wrote: > On Fri, 31 Oct 2008 12:30:46 -0700, "Steve Franks" <[EMAIL PROTECTED]> wrote: >> Let's backup. What's the 'right' way to get a bloody linux program >> that expects all it's headers in /usr/include to compile on freebsd >> where all the headers are in /usr/local/include? That's all I'm >> really asking. Specifically, it's looking for libusb & libftdi. If I >> just type gmake, it can't find it, but if I manually edit the >> Makefiles to add -I/usr/local/include, it can. Obviously, manually >> editing the makefiles is *not* the right way to fix it (plus it's >> driving me crazy). > > Then you run `configure' with the `right' environment: > >env CPPFLAGS='-I/usr/local/include' \ > LDFLAGS='-L/usr/local/lib' ./configure > > The `--includedir' and `--libdir' options are *not* meant to be useful > to the developer that uses the GNU build tools, but to the person who > compiles something for the target host. > > There are several types of people involved in the `release' of a full > program: > >* The maintainer, who uses `automake', `libtool' and `autoconf' to > write portable Makefiles and build tools. > >* The builder, who compiles the program with specific options. > >* The packager, who runs `make install' in the build tree, creates a > set of installed files, and then packages *some* of these files in > a packaging-specific format. > > These types of people commonly have different constraints in the way > they can tweak and twist the GNU build tools, to match their needs. > > 1. The _maintainer_ of the program is free to set up his environment to > include any `CPPFLAGS', `CFLAGS' or `LDFLAGS' they find useful. For > example, if they have an experimental third-party library installed > in a custom location they can use: > > export CPPFLAGS='-I/opt/foolib/include' LDFLAGS='-L/opt/foolib/lib' > ./configure --prefix='/var/tmp/myprog' > > This way `configure' will emit Makefiles that try to use the > third-party library from `/opt/foolib' instead of the system-default > location for header files and libraries. > > This may often be a lot easier than waiting until the necessary bits > are installed in the ``official'' places at development systems. > Developers who want to experiment with a new version of `libfoo', > i.e. to integrate it with the rest of a program, can use custom > `CPPFLAGS' and `LDFLAGS' while everyone else is merrily going along > with the ``standard'' version of the `libfoo' library. > > 2. The _builder_ may be constrained in the sets of options he can pass > to the `CFLAGS'. He is, after all, testing how a pristine, clean > version of the program can build in what is defined as the ``official > release'' environment. > > He may be allowed to tinker with include paths and library paths, but > it is often safer to wrap the build process in scripts and tools that > yield a repeatable, verifiable build process. This may preclude the > use of options like `-I/custom/hdr/path' and `-L/custom/lib/path'. > > The builder of a program may not be an actual person, but a cron job > or another automated process, i.e. a `nightly build' script that runs > a clean build in a pristine environment, verifies that it can all > complete without errors, and then emails one or more reports. > > When the builder _is_ a real person, he may be sharing roles with the > third type of person involved in the build life of a program that > uses the GNU build tools: the packaging person. > > 3. The _packager_ is someone who runs `make install', to produce the > final program distribution and then bundles parts of or even all the > files that are produced by the usual `install' target of GNU tools. > The installation of all the files may be done in the default > installation `prefix', but it may also be redirected to a staging > area by setting `DESTDIR' in the environment: > > mkdir /var/tmp/proto > env DESTDIR=/var/tmp/proto make install > > Depending on the type of the target system, and on particular needs >
Re: includes, configure, /usr/lib vs. /usr/local/lib, and linux coders
On Fri, Oct 31, 2008 at 12:11 PM, Nate Eldredge <[EMAIL PROTECTED]> wrote: > On Fri, 31 Oct 2008, Steve Franks wrote: > >> I believe someone has told me on this list that the proper way to >> compile a linux program is to run configure >> --includedir=/usr/local/include --libdir=/usr/local/lib. > > Nitpick: not specifically a Linux program, but a program using a configure > script generated by GNU's autoconf system. Programs using autoconf may > run on systems other than Linux (usually do, in fact, since the point of > autoconf is portability), and many Linux programs don't use autoconf. > > And I'll assume that by 'linux' you actually mean FreeBSD, in order for this > to be on-topic for this list :) > >> Is that >> correct? I've got a bunch of linux weenies trying to tell me their >> code isn't broken because I'm supposed to have headers where theirs >> are. > > I don't understand this sentence. > >> They state that includedir is used by *their* project to locate >> it's *own* headers, so they never bothered to wire it up in >> Makefile.init gets ignored entirely. >> >> I figured I'd better know what I'm talking about before I tell someone >> they are 'wrong'. Especially as it's usually me ;) > > It looks to me like both of you are wrong. :) Looking at the configure that > comes with wget-1.11.2, running configure --help says > > Fine tuning of the installation directories: > ... > --libdir=DIR object code libraries [EPREFIX/lib] > --includedir=DIR C header files [PREFIX/include] > > So it looks like --libdir is supposed to specify where libraries are to be > *installed*, not where they are to be searched for. > > Further up in the help we have > > --prefix=PREFIX install architecture-independent files in PREFIX > [/usr/local] > --exec-prefix=EPREFIX install architecture-dependent files in EPREFIX > [PREFIX] > > So libraries would already be installed in /usr/local/lib by default, unless > you used a --prefix or --exec-prefix option to override that. Similarly for > include files. > > If you need the program being built to search for libraries or include files > in a certain place (such as /usr/local/include and /usr/local/lib, which are > not searched by default on FreeBSD), AFAIK the right way to do it is to set > the LIBRARY_PATH and C_INCLUDE_PATH (or CPLUS_INCLUDE_PATH) environment > variables. > > -- > > Nate Eldredge > [EMAIL PROTECTED] > Let's backup. What's the 'right' way to get a bloody linux program that expects all it's headers in /usr/include to compile on freebsd where all the headers are in /usr/local/include? That's all I'm really asking. Specifically, it's looking for libusb & libftdi. If I just type gmake, it can't find it, but if I manually edit the Makefiles to add -I/usr/local/include, it can. Obviously, manually editing the makefiles is *not* the right way to fix it (plus it's driving me crazy). Steve Steve ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
includes, configure, /usr/lib vs. /usr/local/lib, and linux coders
I believe someone has told me on this list that the proper way to compile a linux program is to run configure --includedir=/usr/local/include --libdir=/usr/local/lib. Is that correct? I've got a bunch of linux weenies trying to tell me their code isn't broken because I'm supposed to have headers where theirs are. They state that includedir is used by *their* project to locate it's *own* headers, so they never bothered to wire it up in Makefile.init gets ignored entirely. I figured I'd better know what I'm talking about before I tell someone they are 'wrong'. Especially as it's usually me ;) Steve ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: neophyte: tcsetattr() gives 22 error in i386, not in amd64?
>> Hi, >> >> I'm getting a 22 errno from tcsetattr() on 7-STABLE i386 in code which >> was working under 7-STABLE amd64. Serial device is a ucom (silabs >> cp2103). Permissions on /dev/cuaU0 look fine. Cutecom/Minicom >> appears to open the port without error... >> >>> I don't see anything obviously wrong, but I'd bet a bug related to >> >>> 32/64-bit types. Can you post a complete piece of code that can be >> >>> compiled and run and demonstrates the problem? Also, try compiling with >> >>> -Wall -W and investigate any warnings that are produced. >> >>> >> >>> By the way, errno 22 is EINVAL, "Invalid argument". perror() is your >> >>> friend. >> >> Strange freebsd doesnt document error numbers. On POSIX, errno 22 is >> >> EINVAL as well (documented in errno(3)). Is this applicable to freebsd? >> > >> > /usr/include/errno.h isn't documentation of error numbers? >> > If you're wanting to track down how/why tcsetattr(3) results in EINVAL, > using truss or ktrace might come in handy. Otherwise, you literally > will have to throw some debugging code into the ucom(4) driver to > try and figure out what function is kicking out code 22. Wow! truss is quite handy. I've located the problem, and am posting it for posterity: Someone was memset()'ing the termios struct to zero's, then setting the baudrate (setcfspeed) and a couple other things. Apparently this was not a canonical set of required members of the struct, because adding a tcgetattr(f, termio) right after the memset apparently pre-populated the thing correctly and now it works fine... Thanks for the leg up, Jeremy. Best, Steve ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
neophyte: tcsetattr() gives 22 error in i386, not in amd64?
Hi,
I'm getting a 22 errno from tcsetattr() on 7-STABLE i386 in code which
was working under 7-STABLE amd64. Serial device is a ucom (silabs
cp2103). Permissions on /dev/cuaU0 look fine. Cutecom/Minicom
appears to open the port without error...
Ideas?
Thanks,
Steve
if(cfsetspeed(&IspEnvironment->newtio,(speed_t)
strtol(IspEnvironment->baud_rate,NULL,10))) {
DebugPrintf(1, "baudrate %s not supported\n",
IspEnvironment->baud_rate);
exit(3);
};
switch (atol(IspEnvironment->baud_rate))
{
case 1152000: NEWTERMIOS_SETBAUDARTE(B1152000); break;
default:
{
DebugPrintf(1, "unknown baudrate %s\n",
IspEnvironment->baud_rate);
exit(3);
}
}
IspEnvironment->newtio.c_iflag = IGNPAR | IGNBRK | IXON | IXOFF;
IspEnvironment->newtio.c_oflag = 0;
/* set input mode (non-canonical, no echo,...) */
IspEnvironment->newtio.c_lflag = 0;
cfmakeraw(&IspEnvironment->newtio);
IspEnvironment->newtio.c_cc[VTIME]= 1; /* inter-character
timer used */
IspEnvironment->newtio.c_cc[VMIN] = 0; /* blocking read
until 0 chars received */
tcflush(IspEnvironment->fdCom, TCIFLUSH);
int err = tcsetattr(IspEnvironment->fdCom, TCSANOW,
&IspEnvironment->newtio);
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
proper types for printf()-ing pointers on amd64 that won't break i386?
Hi, I'm trying to correct some warnings in a port marked ONLY_FOR_ARCHS=i386. They stem from casting a pointer (which I assume is a 64-bit unsigned) to "unsigned int" which is apparently 32 bits? I sort of thought int was supposed to be the atomic register size, but no doubt that would break more than it would help, so it's 32-bits. Anyways, what's the right way to fix this? The port actually works fine as-is on amd64, so I can only assume something was fixed for 7.1, or someone was being extra cautious with the i386 tag. The code: typedef unsigned int cardinal; ... fprintf(stderr, "Mode Table Offset: $C + $%x\n", ((cardinal)map->mode_table) - ((cardinal)map->bios_ptr)); Can I just ditch the cast+%x and use %p? I don't have an i386 system to test on, and I don't want to break anything if I submit a patch... Thanks, Steve ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
correct #define in source to specify FBSD vs. linux?
Seems there is a more appropriate list for my earlier question to freebsd-questions: On and on I charge porting linux engineering tools. Major pita. I see a bunch of #ifdef __APPLE__ lines to pull in alternate headers; what's the equiv for FreeBSD? Thanks, Steve ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
CLOCK_REALTIME undefined on my system
The manpage
(http://www.freebsd.org/cgi/man.cgi?query=clock_gettime&sektion=2&apropos=0&manpath=FreeBSD+7.0-RELEASE)
for clock_gettime() specifies the correct header as , which I
am using, and I don't see any errors on clock_gettime(), but the param
I need, listed in the manpage, CLOCK_REALTIME is undefined. Any ideas
how this could be? I've recently cvsup'd standard-supfile, so you'd
think I'm up to date...
I'm also getting an implicit declaration of isnormal(), and math.h is
clearly included...
Steve
/*
* fclock.c
*
* Copyright (C) 2005 Hein Roehrig
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; either version 2
* of the License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA
* 02111-1307, USA.
*
*/
#define _ISOC99_SOURCE
#define _POSIX_C_SOURCE 199309L
#include
#include
#include
#include
#ifndef __MINGW32__
#include
#endif
#include
#include
/* -- */
#ifdef __APPLE__
#include
#include
#include
long double
frealtime()
{
long double result;
static uint64_t start_mat;
static long double start_time;
static double multiplier;
mach_timebase_info_data_t mtid;
struct timeval tv;
if(!mtid.denom == 0) {
mach_timebase_info(&mtid);
multiplier = (double)mtid.numer / (double)mtid.denom;
gettimeofday(&tv, NULL);
start_time = (long double)tv.tv_sec + (long double)tv.tv_usec * 1000.0;
start_mat = mach_absolute_time();
}
result = start_time + (mach_absolute_time() - start_mat) * multiplier;
assert(isnormal(result));
assert(result > 0);
return result;
}
#else /* def __APPLE__ */
/* -- */
#ifdef _POSIX_TIMERS
long double
frealtime()
{
long double result;
struct timespec t;
if (clock_gettime(CLOCK_REALTIME, &t)==-1) {
perror("frealtime (clock_gettime)");
exit(EXIT_FAILURE);
}
result = (long double)t.tv_sec + (long double)t.tv_nsec*(long double)1e-9;
assert(isnormal(result));
assert(result > 0);
return result;
}
#else /* def _POSIX_TIMERS */
/* -- */
#ifdef __MINGW32__
#include
long double
frealtime()
{
long double result;
struct timeb t;
ftime(&t);
result = (long double)t.time + (long double)t.millitm * (long double)1e-3;
assert(isnormal(result));
assert(result > 0);
return result;
}
#else /* def __MINGW32__ */
/* -- */
#ifndef CLK_TCK
static clock_t CLK_TCK = 0;
static void set_clk_tck(void) __attribute__ ((constructor));
static void set_clk_tck(void)
{
long v = sysconf(_SC_CLK_TCK);
if (v == -1) {
perror("sysconf(_SC_CLK_TCK)");
exit(EXIT_FAILURE);
}
CLK_TCK = v;
}
#endif
long double
frealtime()
{
long double result;
struct tms t;
clock_t c=times(&t);
if (c==(clock_t)-1) {
perror("frealtime (times)");
exit(EXIT_FAILURE);
}
result = (long double)c/CLK_TCK;
assert(isnormal(result));
assert(result > 0);
return result;
}
#endif
#endif
#endif
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
