Re: [IE] Re: [grpc-io] Java 8 end of life for gRPC ?
So if we meet our migration target to move application for Z/OS to GCP this year, then I think we should be fine Either way, it sound like Java 8 pubsub client will still be fine in the meantime *Russell Shaw* Software Engineer - Career Acro Database Support Equifax Inc. O 470-750-2979 Ext.32444 C 678-243-8579 russell.s...@equifax.com On Mon, Feb 14, 2022 at 2:37 PM Eric Anderson wrote: > On Fri, Jan 28, 2022 at 7:19 AM 'Russell Shaw' via grpc.io > <https://protect2.fireeye.com/v1/url?k=31323334-501d2dca-313219e2-454455534531-7bbb357ac779b069=1=11374eae-bb20-4b72-8695-dcf9977f35d7=http%3A%2F%2Fgrpc.io%2F> > wrote: > >> Our company uses Java8 on Z/OS > > > The TL;DR for all this stuff is probably: For Google Cloud users, overall > I'd expect service-specific issues to crop up more than gRPC compatibility > issues. For example, if you want to use a new service, the library may only > support Java 11+. But you really want a plan to upgrade to Java 11 and > beyond. > > Thank you so much for the email. We really do want to hear trouble caused, > as otherwise there's no feedback loop. Sorry for the delay, your email was > just brought to my attention. > > In your specific case, it looks like IBM's Java 11 was only recently made > available > <https://community.ibm.com/community/user/ibmz-and-linuxone/blogs/james-tang1/2021/11/19/ibm-semeru-runtime-certified-edition-for-zos-versi>? > That's a bit worrisome, as it only buys you 1.5 more years, as end of > Premier Support of Java 11 is rapidly approaching. I'm going to need to > keep an eye on that. But you aren't *blocked*, right? It is just "gotta > move quickly"? > > I'll note that practically speaking I doubt we'll actually drop Java 8 in > March. I mainly wanted people to realize *that we could*, because we > really need to have these conversations now and then when we delay it is > perceived as niceness :-). I expect gRPC will wait until ~June before > dropping Java 8, because dropping Java 8 hasn't been on user's radar until > recently. > > But that may not hold for the rest of the Google client libraries. You as > a Google Cloud library consumer are intended to be insulated from gRPC, so > you should really only need to track the Google Cloud libraries. > > I am guessing that the final gRPCJava version built via Java 8, will still >> be able to talk to Pubsub for a while, until the PubSub/gRPC protocols >> changes enough that it eventually breaks. >> > > In that case Pubsub support policies still apply. See Google's Java > supported version documentation > <https://protect2.fireeye.com/v1/url?k=31323334-501d2dca-313219e2-454455534531-4d7a417a3b338587=1=11374eae-bb20-4b72-8695-dcf9977f35d7=https%3A%2F%2Fcloud.google.com%2Fjava%2Fdocs%2Fsupported-java-versions> > . > > gRPC v1.44.0 is still compatible with v1.0.0. A backward incompatible > change would be a big deal and probably need a multi-year migration > process. I know of no features currently discussed that would need to break > the protocol. (Sure, a new feature may need both sides to be upgraded *to > be used*, but then you just wouldn't benefit from the feature.) I > wouldn't be concerned about protocol breakages in the low-single-digit > years time frame. > > There could, however, be behavior changes which don't impact correctness > but could impact performance or similar. This is less likely about gRPC > specific implementation but instead the HTTP/2 ecosystem or auth or > $SOME_OTHER_NON_GRPC_BUT_RELATED topic. These are managed by the Google > service support policies. Google will almost certainly try to avoid these, > but if something crops up you'd go through the Google support processes. > Not speaking authoritatively, but if there's a case of 1-5% performance > decrease, then that just may be the price paid. But something like a 75% > decrease is more like a service deprecation with notifications, etc. Google > can track usage of the old versions via the User-Agent. > > Is there any Google Cloud Platform information on "no longer supported" >> versions of Pubsub / grpcjava jars / cloud-boms? I can't find it mentioned. >> > > I thought I had seen something about library versions being supported for > a year, but it might be in support contracts or similar non-public > documentation, or I just may be wrong. The Java version support policy does > clearly define that the Java 7 releases are best effort. I'd expect Java 8 > to be included in that when it reaches its EOL. > -- This message contains proprietary information from Equifax which may be confidential. If you are not an intended recipient, please refrain from any disclosure, copying, distribution or use of this information and note that su
[grpc-io] Java 8 end of life for gRPC ?
Regarding the below comment in recent release notes.. "Java 8 users pay note: per gRFC P5, gRPC may drop Java 8 support as soon as March this year. If this is expected to cause undue hardship or community issues, please contact us via a GitHub issue or grpc-io@googlegroups.com <https://protect2.fireeye.com/v1/url?k=31323334-501d2dca-313219e2-454455534531-dfcff0d256759d70=1=faeeed93-cb38-4ee5-99f9-66403283ead0=https%3A%2F%2Fgroups.google.com%2Fg%2Fgrpc-io> ." Our company uses Java8 on Z/OS, and uses Google PubSub (which internally uses gRPCJava) to send to GCP cloud environments. I am guessing that the final gRPCJava version built via Java 8, will still be able to talk to Pubsub for a while, until the PubSub/gRPC protocols changes enough that it eventually breaks. What are the chances of this happening ? ie Are the protocols basically set and therefore won't break ? Is there any Google Cloud Platform information on "no longer supported" versions of Pubsub / grpcjava jars / cloud-boms? I can't find it mentioned. Cheers, Russell *Russell Shaw* Software Engineer - Career Acro Database Support Equifax Inc. O 470-750-2979 Ext.32444 C 678-243-8579 russell.s...@equifax.com -- This message contains proprietary information from Equifax which may be confidential. If you are not an intended recipient, please refrain from any disclosure, copying, distribution or use of this information and note that such actions are prohibited. If you have received this transmission in error, please notify by e-mail postmas...@equifax.com <mailto:postmas...@equifax.com>. Equifax® is a registered trademark of Equifax Inc. All rights reserved. -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/CAMBh4745FkUJMkqGSzN5wCjkpoSnMgyGyb24DW9eET-wmh77gQ%40mail.gmail.com.
Re: static class member as interrupt handler works, but not if class is templated
On 11/4/21 8:36 am, Trampas Stern wrote: Actually C++ is not slower or more bloat than C, depending on the features used. For example I do not use RTTI or exceptions, so that makes it about the same as C for size. Yes you have to turn these features off in your compiler (-fno-rtti, -fno-exceptions). Sure you have trampolines or jump tables for function overloading but you have to do the same in C. If you do not use inheritance or function overloading you do not have the penalty. Function overloading is a compile-time concept, but the result after name scope flattening are simple function names that are called without any extra pointer indirections (ie, no different than C). C++ is as efficient as C only if what is written translates to the equivalent form. This is easy to do, but only after a large hurdle of understanding how C++ compilers work. The biggest shortcoming in the C++ "industry" is that there is no literature i have seen that explains in a compact way how you can look at a piece of C++ code and see how it would translate to the equivalent assembly, which is the main advantage of C.
Re: Future plans for Autotools
On 21/1/21 9:15 am, Zack Weinberg wrote: Now we've all had a while to recover from the long-awaited Autoconf 2.70 release, I'd like to start a conversation about where the Autotools in general might be going in the future. Clearly any future development depends on finding people who will do the work, but before we worry about that I think we might want to figure out what work we _want_ to do. ... Agree with all that. The biggest problem i had that wasted the most time is that none of the documentation gave a good overview of the sequence of steps the main perl script did to process the files and produce the output, and intermediate files involved. Using a language like C++ where a step-by-step debugger like gdb can be used would have been good. Having a nuts and bolts low level detail of how it all works makes one much more productive. I'm talking of real software engineering ppl that understand compilers and not programmers that are really artist dabbling users. It is the real engineers that are more motivated to understand and be contributors. As a result, i only gradually got proficient over a few years, and having to comprehend a large manual on ancient shell variants and study M4 didn't help. M4 is easy if there's a decent tutorial readily available. Currently one needs to download other manuals and tutorials to get a good idea of it, and it's a big step for starting programmers. I understand mostly how things work, but got bogged down in understanding the perl script. If i mastered it all, i'd think more about what can be changed or improved. I did one early iteration of a tool that did the functions of 'make' using an input description of the files one wanted in a project. It also had its own shell implementation. Users would need a copy of that shell installed. An idea was to have the users script automatically build and install the shell in a location the user or system dictated. Another option was an automatic download from a trusted place. I could get more done if i had another go at it, but i'm too busy on a different tool. If GNU paperwork gets in the way, just bypass it and release new stuff as BSD. Then it's truly free.
Re: determine base type of a typedef
On 23/10/20 6:06 pm, Russell Shaw wrote: On 23/10/20 5:54 pm, Anatoli wrote: Russell, Thanks for your suggestion. The problem is, as I mentioned in the initial post, on amd64 sizeof(time_t) is always 8 bytes, as well as long and long long, so sizeof(time_t) == sizeof(long int) == sizeof(long long int). I've actually tried the following directly in configure.ac (for this test it's not needed to run a custom code): #if (SIZEOF_TIME_T == SIZEOF_LONG_LONG_INT) #define TIME_T_FMT "%lld" #elif (SIZEOF_TIME_T == SIZEOF_LONG) #define TIME_T_FMT "%ld" #else #error dont know what to use for TIME_T_FMT #endif But both checks are true so it makes no sense. I need something that would not depend on the size of the type. Not sure it's even possible. I might be missing something simple because i got up too early. If a platform has time_t the same size as a long and long long, does it matter whether the printf uses "%ld" or "%lld" ? [For GNU C this is "the same" as both are of 8 bytes, but clang generates a warning like: "warning: format specifies type 'long' but the argument has type 'time_t' (aka 'long long')".] I see that is the actual problem. If the compiler complains, then maybe you could capture that complaint output. Bit of a messy test.
Re: determine base type of a typedef
On 23/10/20 6:06 pm, Russell Shaw wrote: On 23/10/20 5:54 pm, Anatoli wrote: Russell, Thanks for your suggestion. The problem is, as I mentioned in the initial post, on amd64 sizeof(time_t) is always 8 bytes, as well as long and long long, so sizeof(time_t) == sizeof(long int) == sizeof(long long int). I've actually tried the following directly in configure.ac (for this test it's not needed to run a custom code): #if (SIZEOF_TIME_T == SIZEOF_LONG_LONG_INT) #define TIME_T_FMT "%lld" #elif (SIZEOF_TIME_T == SIZEOF_LONG) #define TIME_T_FMT "%ld" #else #error dont know what to use for TIME_T_FMT #endif But both checks are true so it makes no sense. I need something that would not depend on the size of the type. Not sure it's even possible. I might be missing something simple because i got up too early. If a platform has time_t the same size as a long and long long, does it matter whether the printf uses "%ld" or "%lld" ? [For GNU C this is "the same" as both are of 8 bytes, but clang generates a warning like: "warning: format specifies type 'long' but the argument has type 'time_t' (aka 'long long')".] I see that is the actual problem.
Re: determine base type of a typedef
On 23/10/20 5:54 pm, Anatoli wrote: Russell, Thanks for your suggestion. The problem is, as I mentioned in the initial post, on amd64 sizeof(time_t) is always 8 bytes, as well as long and long long, so sizeof(time_t) == sizeof(long int) == sizeof(long long int). I've actually tried the following directly in configure.ac (for this test it's not needed to run a custom code): #if (SIZEOF_TIME_T == SIZEOF_LONG_LONG_INT) #define TIME_T_FMT "%lld" #elif (SIZEOF_TIME_T == SIZEOF_LONG) #define TIME_T_FMT "%ld" #else #error dont know what to use for TIME_T_FMT #endif But both checks are true so it makes no sense. I need something that would not depend on the size of the type. Not sure it's even possible. I might be missing something simple because i got up too early. If a platform has time_t the same size as a long and long long, does it matter whether the printf uses "%ld" or "%lld" ?
Re: determine base type of a typedef
On 23/10/20 9:23 am, Anatoli wrote:
Hi All,
Is there a way to determine with autoconf what's the base type of a typedef?
I'm trying to accomplish the following:
There are standard types time_t, off_t, size_t and similar that are defined
differently on different platforms/OS.
For example, time_t is defined as "long int" on Linux amd64, but as "long
long int" on OpenBSD amd64. So when printing a time_t var with printf & co,
on Linux it's OK to use "%ld" format specifier, but on OpenBSD it should be
"%lld".
You could use an AC_COMPILE thing to run a small bit of C that does something
like:
int
test(int argc, char **argv)
{
time_t t = -1;
if(t < 0) {
if(sizeof(time_t) == sizeof(int)) {
printf("d");
}
else if(sizeof(time_t) == sizeof(long int)) {
printf("ld");
}
else if(sizeof(time_t) == sizeof(long long int)) {
printf("lld");
}
else {
printf("error");
}
}
else {
if(sizeof(time_t) == sizeof(int)) {
printf("u");
}
else if(sizeof(time_t) == sizeof(long int)) {
printf("lu");
}
else if(sizeof(time_t) == sizeof(long long int)) {
printf("llu");
}
else {
printf("error");
}
}
return 0;
}
Re: How to change the shebang in 'configure' to require Bash
On 20/03/18 22:53, Russell Shaw wrote: On 20/03/18 21:07, R. Diez wrote: ... Requiring a POSIX shell in the next version is an improvement, but POSIX is too limiting to really help. It is 2018. No wonder so many people want to ditch Autoconf! Autoconf is hard to learn because becoming properly familiar with shell programming is hard enough for new shell hackers, let alone figuring out the several versions of Bourne-like shells around and their extensions, plus reading all that posix standards stuff, then having to read all about and mastering M4. An alternative way to portability would be to ditch M4 so that everything is done directly in a shell that comes with autoconf. The shell could have inbuilt functions for the common things needed like regular expressions etc. I'll need to reword that. If autoconf'd programs required the end users to have an installation-shell that is ported to all systems of interest, then the learning requirements of autoconf users should be a lot less. ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: How to change the shebang in 'configure' to require Bash
On 20/03/18 21:07, R. Diez wrote: ... Requiring a POSIX shell in the next version is an improvement, but POSIX is too limiting to really help. It is 2018. No wonder so many people want to ditch Autoconf! Autoconf is hard to learn because becoming properly familiar with shell programming is hard enough for new shell hackers, let alone figuring out the several versions of Bourne-like shells around and their extensions, plus reading all that posix standards stuff, then having to read all about and mastering M4. An alternative way to portability would be to ditch M4 so that everything is done directly in a shell that comes with autoconf. The shell could have inbuilt functions for the common things needed like regular expressions etc. ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: Ggradebook; request for assistance
On 12/02/17 01:28, Norbert de Jonge wrote: Hi, The following is my reply to someone who recently sent me an e-mail with a modified Ggradebook 0.92 that includes autoconf/automake. First of all, I sincerely appreciate you looking into it. What you've created is not quite what I'm looking for. Please (re)read point #2 in my announcement: http://lists.gnu.org/archive/html/ggradebook-devel/2017-02/msg1.html I would like the top level (root directory) to be empty. What autoconf/automake normally do is mess up the top level. These build tools require many different (separate) files, and as a result this programming tool starts dominating - it takes over - the entire package with its crap. It's very ugly, in my opinion. If all its files cannot live in their own auto/ directory or something similar, and then address (talk to) 1 or 2 files in the other directories to get work done, then I don't want autoconf/automake. Currently, the package uses a simple Makefile in the src/ directory, and with the exception of "make install" it's doing the job. I don't want autoconf/automake to make a mess of this package. It should be happy that I'm willing to give it its own directory and gets more than a single file. :) Also, I would like the user to get a warning if their GTK+ or GStreamer version is _newer_ than what is targeted. GTK+ in particular is a library that has the potential to create compatibility issues, and it deprecates functions constantly. I want users to know that any kind of warnings the application is throwing, or any unintended behavior its displaying, _may_ be the result of non-matching library versions. My simple Makefile has a decent implementation of this. Another problem with your package is the following. This program has directories with content that it relies on. These directories are docs/, ogg/ and pix/. If a user runs "make", the executable should be moved into the parent directory for it to find files in those directories. Related to this, and equally important, is that "make install" should take into account the aforementioned directories and that PKGDATADIR in the source code should (thus) be respected. In the package you sent me, there are no autoconf/automake related files in, for example, the ogg/ directory. This suggests to me that autoconf/automake ignores this directory. I can confirm this suspicion by running "make install", running the program and then selecting "Help..." from the application's Help menu. It cannot find the docs/README.txt file. One last thing. Perhaps autoconf/automake requires this, but... The gcc commands appears to look for header files in directories that I'm unfamiliar with. Including, but not limited to, "/usr/include/at-spi-2.0", "/usr/include/dbus-1.0", "/usr/include/gio-unix-2.0/", "/usr/include/mirclient" and "/usr/include/harfbuzz". I'm certain that at least some of those are not used with my Makefile. Maybe configure.ac is adding unnecessary headers? I don't know enough about the tool to be sure. I'm aware that I'm asking for a lot. Especially considering that I'm hoping someone else will take on and finish this task in its entirety. Hi, I'm too busy to go into great detail with everything, but atleast it's a start. I did it to take a break from the programming i was doing, but one thing for certain is that i'm a gtk (and Qt) hater ;) ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: Autoconf and a bare-metal host with no C library
On 13/10/16 13:11, Luca Saiu wrote: ... > So, what I'm asking you is: does a clean solution exist, or compiling > without a runtime library is just not supported by the Autotools? It > sounds weird to say that for configuring you need a cross-compiler with > support for a runtime that will never even be linked when building. > Shouldn't there be, at least, one variant of AC_PROG_CC which doesn't > fail in a fatal way? > > I'm not yet linking the code in a public forum just because it still > lacks copyright and license headers; but in case it were useful to you, > even if I doubt it, I can clean it up and publish it. It can be messy and take quite some time to figure out what to do, but this kind of stuff is handled in the autoconf/automake/autogen build system of binutils and gcc. Not a quick and easy path for the uninitiated though. ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
"inline" using a variable
Hi,
When i "configured" binutils in a directory separate to the source directory, it
generates a 11500 line Makefile containing the following fragment.
Down the bottom it does:
$(MAKE) $(RECURSE_FLAGS_TO_PASS) all-stage1;
but "all-stage1" is not in the Makefile. I think it's got something to do with:
stage:
@: $(MAKE); $(stage)
but i don't understand the description below of what that does.
Fragment:
# -
# GCC bootstrap support
# -
# We track the current stage (the one in 'gcc') in the stage_current file.
# stage_last instead tracks the stage that was built last. These targets
# are dummy when toplevel bootstrap is not active.
# While making host and target tools, symlinks to the final stage must be
# there, so $(unstage) should be run at various points. To avoid excessive
# recursive invocations of make, we "inline" them using a variable. These
# must be referenced as ": $(MAKE) ; $(unstage)" rather than "$(unstage)"
# to avoid warnings from the GNU Make job server.
unstage = :
stage = :
current_stage = ""
.PHONY: unstage stage
unstage:
@: $(MAKE); $(unstage)
stage:
@: $(MAKE); $(stage)
# Disable commands for lean bootstrap.
LEAN = false
# We name the build directories for the various stages "stage1-gcc",
# "stage2-gcc","stage3-gcc", etc.
# Since the 'compare' process will fail (on debugging information) if any
# directory names are different, we need to link the gcc directory for
# the previous stage to a constant name ('prev-gcc'), and to make the name of
# the build directories constant as well. For the latter, we use naked names
# like 'gcc', because the scripts in that directory assume it. We use
# mv on platforms where symlinks to directories do not work or are not
# reliable.
# 'touch' doesn't work right on some platforms.
STAMP = echo timestamp >
# We only want to compare .o files, so set this!
objext = .o
.PHONY: stage1-start stage1-end
stage1-start::
@: $(MAKE); $(stage); \
echo stage1 > stage_current ; \
echo stage1 > stage_last; \
$(SHELL) $(srcdir)/mkinstalldirs $(HOST_SUBDIR)
@cd $(HOST_SUBDIR); [ -d stage1-bfd ] || \
mkdir stage1-bfd; \
mv stage1-bfd bfd
@cd $(HOST_SUBDIR); [ -d stage1-opcodes ] || \
mkdir stage1-opcodes; \
mv stage1-opcodes opcodes
@cd $(HOST_SUBDIR); [ -d stage1-binutils ] || \
mkdir stage1-binutils; \
mv stage1-binutils binutils
@cd $(HOST_SUBDIR); [ -d stage1-gas ] || \
mkdir stage1-gas; \
mv stage1-gas gas
@cd $(HOST_SUBDIR); [ -d stage1-intl ] || \
mkdir stage1-intl; \
mv stage1-intl intl
@cd $(HOST_SUBDIR); [ -d stage1-ld ] || \
mkdir stage1-ld; \
mv stage1-ld ld
@cd $(HOST_SUBDIR); [ -d stage1-libiberty ] || \
mkdir stage1-libiberty; \
mv stage1-libiberty libiberty
@[ -d stage1-$(TARGET_SUBDIR) ] || \
mkdir stage1-$(TARGET_SUBDIR); \
mv stage1-$(TARGET_SUBDIR) $(TARGET_SUBDIR)
stage1-end::
@if test -d $(HOST_SUBDIR)/bfd ; then \
cd $(HOST_SUBDIR); mv bfd stage1-bfd ; \
fi
@if test -d $(HOST_SUBDIR)/opcodes ; then \
cd $(HOST_SUBDIR); mv opcodes stage1-opcodes ; \
fi
@if test -d $(HOST_SUBDIR)/binutils ; then \
cd $(HOST_SUBDIR); mv binutils stage1-binutils ; \
fi
@if test -d $(HOST_SUBDIR)/gas ; then \
cd $(HOST_SUBDIR); mv gas stage1-gas ; \
fi
@if test -d $(HOST_SUBDIR)/intl ; then \
cd $(HOST_SUBDIR); mv intl stage1-intl ; \
fi
@if test -d $(HOST_SUBDIR)/ld ; then \
cd $(HOST_SUBDIR); mv ld stage1-ld ; \
fi
@if test -d $(HOST_SUBDIR)/libiberty ; then \
cd $(HOST_SUBDIR); mv libiberty stage1-libiberty ; \
fi
@if test -d $(TARGET_SUBDIR) ; then \
mv $(TARGET_SUBDIR) stage1-$(TARGET_SUBDIR) ; \
fi
rm -f stage_current
# Bubble a bug fix through all the stages up to stage 1. They are
# remade, but not reconfigured. The next stage (if any) will not be
# reconfigured either.
.PHONY: stage1-bubble
stage1-bubble::
@r=`${PWD_COMMAND}`; export r; \
s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \
if test -f stage1-lean ; then \
echo Skipping rebuild of stage1 ; \
else \
$(MAKE) stage1-start; \
$(MAKE) $(RECURSE_FLAGS_TO_PASS) all-stage1; \
fi
___
Help-make mailing list
Help-make@gnu.org
https://lists.gnu.org/mailman/listinfo/help-make
m4_divert_text
Hi, In binutils/configure.ac there is: m4_divert_text([PARSE_ARGS], [case $srcdir in *" "*) m4_pushdef([AS_MESSAGE_LOG_FD], [])dnl AC_MSG_ERROR([path to source, $srcdir, contains spaces]) m4_popdef([AS_MESSAGE_LOG_FD])dnl ;; esac ac_subdirs_all=`cd $srcdir && echo */configure | sed 's,/configure,,g'` ]) I can't find where it's used, and was wondering how one would use this definition. Doesn't the pushdef/popdef pair make it useless? ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
XPP
Hi, I use the xpp printing panel which has always been a bit buggy, and recently it has become so buggy and crashing as to be unuseable. It is unmaintained upstream, and also an orphaned package. https://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=unstable;package=xpp#_0_3_4 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=573876 I have fixed all the bugs except #630717 (xpp does not support UTF-8) which i could not reproduce. Do i need to be a Debian maintainer or have a gpg key thing to adopt the package? Do i need to put the new code on a web site? -- To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54b29c1d.2050...@netspace.net.au
Re: Automate desired resolution at login
On 19/01/14 07:11, j...@askur.org wrote: When I log into X I seem to have the wrong resolution (My screen: vga 19LCD envision rated at 1440x900). I am able to get around that by typing the following: xrandr --newmode 1440x900_60.00 106.50 1440 1528 1672 1904 900 903 909 934 -hsync +vsync xrandr --addmode VGA-0 1440x900_60.00 xrandr --output VGA-0 --mode 1440x900_60.00 I haven't been able to figure out how to make this happen automatically, i.e. how to save this as the default mode at login. If you look at the log excerpt which is attached you see that there are some modes selected there but I don't know how to change that. I don't know where those modes came from. Trying Xorg -configure was unsuccessful due to Number of screens... Could you make any recommendations or point me in the right direction? You can put the xrandr commands in ~/.Xsession ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: [avr-gcc-list] How to initialize an array of struct?
On 15/12/13 17:20, dfx wrote:
Hi,
After spending more than one day to create an array of struct I have
come to this code:
struct Lamp {
uint8_t highAddress [9] ;
uint8_t lowAddress [9] ;
uint8_t onoff ;
uint8_t active ;
uint8_t power;
uint8_t brightness ;
uint8_t temperatures ;
uint8_t faultCount ;
} ;
struct Lamp lamps [10];
void init () {
struct Lamp lamp0 = { 0013A200 , 4094500D , 0 , 1 , 0 , 0, 0 , 0} ;
struct Lamp lamp1 = { 0013A200 , 40B12530 , 0 , 1 , 0 , 0, 0 , 0} ;
struct Lamp lamp2 = { , , 0 , 0, 0 , 0, 0, 0 };
struct Lamp lamp3 = { , , 0 , 0, 0 , 0, 0, 0 };
struct Lamp lamp4 = { , , 0 , 0, 0 , 0, 0, 0 };
struct Lamp lamp5 = { , , 0 , 0, 0, 0 , 0, 0 };
struct Lamp lamp6 = { , , 0 , 0, 0, 0 , 0, 0 };
struct Lamp lamp7 = { , , 0 , 0, 0, 0 , 0, 0 };
struct Lamp lamp8 = { , , 0 , 0, 0, 0 , 0, 0 };
struct Lamp lamp9 = { , , 0 , 0, 0, 0 , 0, 0 };
lamps [0] = lamp0 ;
lamps [1] = lamp1 ;
lamps [2] = lamp2;
lamps [3] = lamp3 ;
lamps [4] = lamp4 ;
lamps [5] = lamp5 ;
lamps [6] = lamp6 ;
lamps [7] = lamp7 ;
lamps [8] = lamp8 ;
lamps [9] = lamp9 ;
}
it compiles without errors ( and it may be that it works!) but it is
certainly wrong because it consumes twice the memory required (once for
the array [ 10] and another for 10 lamps).
The question is: how can I initialize the array without defining first
ten lamps individually ?
Thank you very much .
struct Lamp {
uint8_t highAddress[11];
uint8_t lowAddress[11];
uint8_t onoff;
uint8_t active;
uint8_t power;
uint8_t brightness;
uint8_t temperatures;
uint8_t faultCount;
} ;
struct Lamp lamps [10] = {
{ 0013A200 , 4094500D , 0, 1, 0, 0, 0, 0},
{ 0013A200 , 40B12530 , 0, 1, 0, 0, 0, 0},
{ , , 0, 0, 0, 0, 0, 0},
{ , , 0, 0, 0, 0, 0, 0},
{ , , 0, 0, 0, 0, 0, 0},
{ , , 0, 0, 0, 0, 0, 0},
{ , , 0, 0, 0, 0, 0, 0},
{ , , 0, 0, 0, 0, 0, 0},
{ , , 0, 0, 0, 0, 0, 0},
{ , , 0, 0, 0, 0, 0, 0},
};
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] How to initialize an array of struct?
On 15/12/13 17:20, dfx wrote:
Hi,
After spending more than one day to create an array of struct I have
come to this code:
struct Lamp {
uint8_t highAddress [9] ;
uint8_t lowAddress [9] ;
uint8_t onoff ;
uint8_t active ;
uint8_t power;
uint8_t brightness ;
uint8_t temperatures ;
uint8_t faultCount ;
} ;
struct Lamp lamps [10];
void init () {
struct Lamp lamp0 = { 0013A200 , 4094500D , 0 , 1 , 0 , 0, 0 , 0} ;
struct Lamp lamp1 = { 0013A200 , 40B12530 , 0 , 1 , 0 , 0, 0 , 0} ;
struct Lamp lamp2 = { , , 0 , 0, 0 , 0, 0, 0 };
struct Lamp lamp3 = { , , 0 , 0, 0 , 0, 0, 0 };
struct Lamp lamp4 = { , , 0 , 0, 0 , 0, 0, 0 };
struct Lamp lamp5 = { , , 0 , 0, 0, 0 , 0, 0 };
struct Lamp lamp6 = { , , 0 , 0, 0, 0 , 0, 0 };
struct Lamp lamp7 = { , , 0 , 0, 0, 0 , 0, 0 };
struct Lamp lamp8 = { , , 0 , 0, 0, 0 , 0, 0 };
struct Lamp lamp9 = { , , 0 , 0, 0, 0 , 0, 0 };
lamps [0] = lamp0 ;
lamps [1] = lamp1 ;
lamps [2] = lamp2;
lamps [3] = lamp3 ;
lamps [4] = lamp4 ;
lamps [5] = lamp5 ;
lamps [6] = lamp6 ;
lamps [7] = lamp7 ;
lamps [8] = lamp8 ;
lamps [9] = lamp9 ;
}
it compiles without errors ( and it may be that it works!) but it is
certainly wrong because it consumes twice the memory required (once for
the array [ 10] and another for 10 lamps).
The question is: how can I initialize the array without defining first
ten lamps individually ?
Thank you very much .
struct Lamp {
uint8_t *highAddress;
uint8_t *lowAddress;
uint8_t onoff;
uint8_t active;
uint8_t power;
uint8_t brightness;
uint8_t temperatures;
uint8_t faultCount;
} ;
struct Lamp lamps [10] = {
{(uint8_t *) 0013A200 , (uint8_t *) 4094500D , 0, 1, 0, 0, 0, 0},
{(uint8_t *) 0013A200 , (uint8_t *) 40B12530 , 0, 1, 0, 0, 0, 0},
{(uint8_t *) , (uint8_t *) , 0, 0, 0, 0, 0, 0},
{(uint8_t *) , (uint8_t *) , 0, 0, 0, 0, 0, 0},
{(uint8_t *) , (uint8_t *) , 0, 0, 0, 0, 0, 0},
{(uint8_t *) , (uint8_t *) , 0, 0, 0, 0, 0, 0},
{(uint8_t *) , (uint8_t *) , 0, 0, 0, 0, 0, 0},
{(uint8_t *) , (uint8_t *) , 0, 0, 0, 0, 0, 0},
{(uint8_t *) , (uint8_t *) , 0, 0, 0, 0, 0, 0},
{(uint8_t *) , (uint8_t *) , 0, 0, 0, 0, 0, 0},
};
The casts can be eliminated if you use normal char * instead of uint8_t.
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: XRANDR outputs
On 16/10/13 08:58, Alex Deucher wrote: On Tue, Oct 15, 2013 at 2:53 AM, Russell Shaw rjs...@netspace.net.au wrote: Hi, After a system upgrade, xrandr no longer reports two monitors connected to the video card. I get: xrandr: Failed to get size of gamma for output default Screen 0: minimum 640 x 400, current 1600 x 1200, maximum 1600 x 1200 default connected 1600x1200+0+0 0mm x 0mm 1600x1200 0.0* 1280x1024 0.0 1152x8640.0 1024x7680.0 800x600 0.0 640x480 0.0 720x400 0.0 Looks like something broke during your upgrade. It looks like ended up with the vesa driver rather than radeon. Check your dmesg output and xorg log. Make sure you have the firmware packages installed for your distro. Hi, I found i had the proprietory fglrx driver installed, but the latest one required an xorg-video-abi-xx that was not available in debian. Uninstalling the fglrx driver and installing the xserver-xorg-video-radeon package fixed the problem. All the font rendering looks smoother now for some reason. ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[Remind-Fans] 5th friday of month
Hi, In a Remind file (test) i have: REM FRI 29 MSG 5th-friday when i run remind -c test, i get an entry on the 2nd and 30th. (today is thursday 1-aug-2013) ___ Remind-fans mailing list Remind-fans@lists.roaringpenguin.com http://lists.roaringpenguin.com/cgi-bin/mailman/listinfo/remind-fans Remind is at http://www.roaringpenguin.com/products/remind
Re: [free-software-melb] CuBox
On 28/06/13 18:27, Glenn McIntosh wrote: On 28/06/13 16:59, Sven@GMX wrote: But in order to programm the Embedded Pi you need to install CoocoxIDE, which is free to use but neither Open Source nor does it run on an Open Source system such as Linux. Unfortunately this creeping lock-in is all too common in the firmware world. Often it is a 'not invented here' corporate dysfunction at play. Many of these IDEs are really only a GUI shell to run openly licenced tools such as gcc (CoocoxIDE is just one of many such IDEs), and don't add anything that couldn't be done in any decent IDE. The hardware specific parts are typically just a few scripts that specify compilation options and uploading/debugging connnections, and perhaps a device specific library. Apart from the lack of openness, I find it a major annoyance when working on multiple firmware platforms, all with inconsistent IDEs and libraries. I think we have to resist such lock-in. For projects where we have control, this may involve separating out the proprietary tools and discarding them (eg, setting up our own scripts for the hardware that can work with a non-proprietary IDE, and making them available to others). If this is not practical, I think it is quite rational to boycott such hardware. There are good business reasons for avoiding vendor lock-in, not to mention the fact that it is your own freedom as a developer that is being restricted here. I never bothered with the Pi because the most important and interesting part (the graphics drivers and graphics register details) is closed. Defeats the point of the whole thing. I wouldn't use a Pi if they were free (as in beer). ___ Free-software-melb mailing list Free-software-melb@lists.softwarefreedom.com.au http://lists.softwarefreedom.com.au/cgi-bin/mailman/listinfo/free-software-melb Free Software Melbourne home page: http://www.freesoftware.asn.au/melb/
Re: [ANNOUNCE] libXi 1.4.99.1
On 09/11/11 12:16, Peter Hutterer wrote: A month late but I just noticed that I never sent an announcement out for this. libXi is the first snapshot for XI 2.1 support. At this point I consider it unlikely that any major protocol changes will happen to the smooth scrolling support. If you're working on a toolkit or similar, I highly recommend to start using the new stuff while we can still change it to fit your expectations better. Hi, I posted this message 4-Nov-2010: quote In XInput2, when i get a XI_HierarchyChanged event after plugging in another mouse, is there a way to get a unique identifier for each device such as a brand and model number? When i start my program that uses two mice for different functions (one in each hand), it would be useful for them both to be assigned the correct role whenever the program is started, regardless of whatever other devices have been plugged in since the last session. unquote I'm not currently working on mouse stuff, but i will again sometime, and will use more than one pointer device simultaneously for CAD programs. Brand and model number and also the port the pointer is plugged into would be useful, in case both devices are the same model. ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: seprate window management component
On 15/09/11 04:33, Michal Suchanek wrote: On 14 September 2011 20:26, Bill Spitzakspit...@gmail.com wrote: I think the idea is that what you are calling the window manager is in fact a library running in the client process and memory space. It would probably be part of the toolkit. Which is utterly wrong. 1) you can't deal with clients malfunctioning 2) now every toolkit would not only look differently but also behave differently, possibly to the point that when running applications using multiple different toolkits your desktop breaks due to WM incompatibility 3) this is not really toolkit specific and should not have to be reimplemented in every toolkit If implementing something in the toolkit makes things easier, then i don't see why that shouldn't be done. All that's needed for consistancy between toolkits is a standard to follow. I wouldn't want policy imposed on my toolkit by an external server i don't like. IIRC, the X icccm defines properties for window groups, and it is up to the application to set those properties correctly and that the WM does the right thing. If they don't do the right thing or are malfunctioning, then just fix them or create an alternative. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: gEDA-user: pcjc2 tessellation
On 29/05/11 23:30, Peter Clifton wrote: On Sun, 2011-05-29 at 11:37 +1000, Russell Shaw wrote: Hi, In _borast_bentley_ottmann_tessellate_bo_edges() which is from _cairo_bentley_ottmann_tessellate_bo_edges(), i see you deleted case CAIRO_BO_EVENT_TYPE_INTERSECTION: What effect does this have on the types of polygons that can be rasterized? Think i know now. Polygons can't have edges that cross other edges. You got it.. PCB doesn't allow self intersecting polygons, so I removed support for rendering them in an attempt to manage the complexity (and hopefully improve speed of) the tessellator. Have you tried changing all that fixed point maths stuff to simple floating point operations? It looks very cpu intensive for the amount of work done. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcjc2 tessellation
On 16/05/11 22:59, Russell Shaw wrote: On 16/05/11 19:26, Peter Clifton wrote: On Mon, 2011-05-16 at 15:54 +1000, Russell Shaw wrote: From pcjc2/src/borast/borast-bentley-ottmann.c, i used some functions to make a small test program to see how bo_contour_to_traps() works. The code is mostly stolen from cairo, then stripped down to a bare minumum (e.g. doesn't deal with intersections in contours, as PCB polygons don't have them). I'd be interested to know what you're working on. Please let me know if you spot anything stupid in the borast/ code, I've not completely cleaned the interfaces up ready for merging yet. (The abstraction between them and PCB is not particularly clean). Hi, In _borast_bentley_ottmann_tessellate_bo_edges() which is from _cairo_bentley_ottmann_tessellate_bo_edges(), i see you deleted case CAIRO_BO_EVENT_TYPE_INTERSECTION: What effect does this have on the types of polygons that can be rasterized? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcjc2 tessellation
On 29/05/11 00:46, Russell Shaw wrote: On 16/05/11 22:59, Russell Shaw wrote: On 16/05/11 19:26, Peter Clifton wrote: On Mon, 2011-05-16 at 15:54 +1000, Russell Shaw wrote: From pcjc2/src/borast/borast-bentley-ottmann.c, i used some functions to make a small test program to see how bo_contour_to_traps() works. The code is mostly stolen from cairo, then stripped down to a bare minumum (e.g. doesn't deal with intersections in contours, as PCB polygons don't have them). I'd be interested to know what you're working on. Please let me know if you spot anything stupid in the borast/ code, I've not completely cleaned the interfaces up ready for merging yet. (The abstraction between them and PCB is not particularly clean). Hi, In _borast_bentley_ottmann_tessellate_bo_edges() which is from _cairo_bentley_ottmann_tessellate_bo_edges(), i see you deleted case CAIRO_BO_EVENT_TYPE_INTERSECTION: What effect does this have on the types of polygons that can be rasterized? Think i know now. Polygons can't have edges that cross other edges. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Reinventing the wheel
On 17/05/2011, John Dotyj...@noqsi.com wrote: On May 17, 2011, at 9:56 AM, Russell Shaw wrote: Most guis hide what they do. I believe in them showing the commands they send internally as a script would (or atleast have the option to show that) so the user can paste the commands into an external file if needed. I've done GUIs that wrap scripts, but it only works in very simple, shallow cases. An API that supports GUI well is very different from an API that supports scripting well. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com On 18/05/11 04:57, Eduardo Costa wrote: Hi guys, That's not true at all John. Have you ever heard/seen a program called Alias Wavefront Maya? It used to be from Silicon Graphics, but they sold it to Autodesk a couple of years ago. A program for 3D CGI which has quite an innovative popup menu system with something called hotboxes and cardinal menus (the one shown bellow). 200% productive, and much better than anyother existing/deployed nowadays: http://imageshack.us/photo/my-images/504/polygonquickmenunothingrx6.jpg/ and driven from MEL (sort of an intepreted c languaje they roled for the purpose of scripting such a huge program). Believe me, you wouldn't even think it is scripted because they didn't abuse of it, yet it lets such menu system be 10 times more powerful! I do share many of your points Russell, while I'm happy (still) using geda. It seems to me is going somewhere I don't really want to be in a future. I've got almost done a c-library I wrote implementing this menu systems for my own programs. Haven't looked at it for a time, but it could work with gtk or other toolkits as long as they allow low level event handling. Anyways, if you are really going for it, and are going to use old'good c, I'll be pleased to hear your thoughts and cooperate. Hi, I'm a gtk hater, and am open to new widget toolkit user interface paradigms, even if it means writing new widgets or toolkits from scratch (which i've done before). I found the useability of a 20yo unix box sch/pcb cad program far better in certain ways than current cad packages. It involved the left hand and an external multi-button puck device in most of the screen-panning operations, leading to much less mouse-finger fatigue. It made all the current Windows cad packages look like kiddies toys by comparison. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Reinventing the wheel
On 18/05/11 12:28, Kai-Martin Knaak wrote: Russell Shaw wrote: The problem with KiCAD is 1) C++, 2) Qt. The problems I encountered with gnetlist were 1) scheme I think Scheme could be made much more attractive in geda if it was adequately explained in documentation or a tutorial. I haven't looked lately to see if there's more documentation on it compared to last time i looked. 2) poor documentation ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Reinventing the wheel
On 19/05/11 02:13, DJ Delorie wrote: I'm a gtk hater, and am open to new widget toolkit user interface paradigms, So, you build pcb with --enable-gui=lesstif ? ;-) I do it with gtk whenever i want to poke at it. I know how gtk works, but it's far too convoluted and burdensome for developing non-trivial widgets for non-trivial applications. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Reinventing the wheel
On 17/05/11 02:44, DJ Delorie wrote: I've always been interested in CAD programs and thought of making a schematic/pcb one from scratch. I've never truly understood why people would rewrite a (potentially) huge application set just because. Why not start with the existing tools and just rewrite the parts you're interested in? Like, start with pcb's HID modules but swap out the core? (and if you really want to get *that* involved in pcb layout tools, there *are* parts of pcb that could stand to be ripped out and replaced... ;) Hi, A schematic/pcb editor is not huge unless it's done in an inelegant way. A very first task i would do is create a decent gui for drawing the symbol and footprint in the schematic/pcb library, and make a decent library browser. Then i would make a drawing mode so that whatever symbol i click on in the schematic, will appear under the mouse in the pcb. Likewise, clicking a pcb symbol hilights it in the schematic. I'd design everything from the ground up to decent reverse annotations so that pin and gate swapping in the pcb appears in the schematic. Hierarchical schematics is a must too. By serializing all the gui actions internally, undo/redo and scripting is easy to add. Creating a schematic and pcb should be done productively within the first hour of never having used the program, yet have no limitations for power users. Everything in geda is 180deg opposite to what i'd do. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Reinventing the wheel
On 17/05/11 22:31, Stefan Salewski wrote: On Tue, 2011-05-17 at 20:36 +1000, Russell Shaw wrote: On 17/05/11 02:44, DJ Delorie wrote: Hi, A schematic/pcb editor is not huge unless it's done in an inelegant way. A very first task i would do is create a decent gui for drawing the symbol and footprint in the schematic/pcb library, and make a decent library browser. Then i would make a drawing mode so that whatever symbol i click on in the schematic, will appear under the mouse in the pcb. Likewise, clicking a pcb symbol hilights it in the schematic. I'd design everything from the ground up to decent reverse annotations so that pin and gate swapping in the pcb appears in the schematic. Hierarchical schematics is a must too. By serializing all the gui actions internally, undo/redo and scripting is easy to add. Creating a schematic and pcb should be done productively within the first hour of never having used the program, yet have no limitations for power users. Everything in geda is 180deg opposite to what i'd do. gEDA/PCB may be not the ultimate tools, but they work not bad, when you have learned to use them. (I guess for KiCAD it is similar) Most other commercial tools, like the popular eagle, or the more than 10k Euro professional tools, needs a long learning period. I was told that companies consider a 3 month learning period with seminars for employees when they switch their 10k professionals tools. EDA design is different from custom office tools! And an application interface is not bad, just because it is not like latest Apple/Windows style. I really would be happy if we can try YOUR EDA suite soon -- but I know how fast these great projects can fail. Your sentence I was expert at using high-end HP DCS/PCDS on unix boxes 20 years ago before it got discontinued, and a few other cad systems since then. A very first task i would do is create a decent gui for drawing the symbol and footprint in the schematic/pcb library, and make a decent library browser. makes me not really confident. I've thought of all the implementation and usage problems for a *long* time. I've been coding on lower level problems for quite a while too. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Reinventing the wheel
On 17/05/11 22:40, John Doty wrote: On May 17, 2011, at 4:36 AM, Russell Shaw wrote: Hi, A schematic/pcb editor is not huge unless it's done in an inelegant way. A very first task i would do is create a decent gui for drawing the symbol and footprint in the schematic/pcb library, and make a decent library browser. Then i would make a drawing mode so that whatever symbol i click on in the schematic, will appear under the mouse in the pcb. Likewise, clicking a pcb symbol hilights it in the schematic. I'd design everything from the ground up to decent reverse annotations so that pin and gate swapping in the pcb appears in the schematic. Hierarchical schematics is a must too. OK, you want an integrated tool. Integrated tools are great: I have a nice, handy multitool on my belt. It's the tool I use most. By serializing all the gui actions internally, undo/redo and scripting is easy to add. Creating a schematic and pcb should be done productively within the first hour of never having used the program, yet have no limitations for power users. Impossible. A multitool cannot do all of the things a well-stocked workshop can. The architectures are different. A well-stocked workshop is nothing more than a multitool workshop. There's no reason why a schematic and pcb editor can't have tight coupling and still interact with all external tools. The only disadvantage to external tools is that an interface layer is needed. The coupling could simply be an ipc protocol between separate programs. Your program will probably never export designs to other layout programs. It will never support a variety of simulators. It will never support symbolic circuit analysis. It will never support scripted documentation generation. Or the other things in the open-ended list a toolkit can support. A main priority was to draw schematics for input to a spice or microwave circuit simulator (simulator writing is my other interest), and have an easy gui way of displaying the results. That's fine for an integrated tool: target the specific flow you want. It's no doubt what the majority of users would prefer, at least at the start, and gEDA will still be around for those who need more. Everything in geda is 180deg opposite to what i'd do. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Reinventing the wheel
On 17/05/11 23:43, Stefan Salewski wrote: On Tue, 2011-05-17 at 23:35 +1000, Russell Shaw wrote: I was expert at using high-end HP DCS/PCDS on unix boxes 20 years ago before it got discontinued, and a few other cad systems since then. A very first task i would do is create a decent gui for drawing the symbol and footprint in the schematic/pcb library, and make a decent library browser. makes me not really confident. I've thought of all the implementation and usage problems for a *long* time. I've been coding on lower level problems for quite a while too. Great -- the FOSS EDA world really needs some more smart and active people. Instead of blindly reinventing the wheel, i always look in detail at what currently exists. The more i figure out geda, maybe i could do something with it. It's just that i have to do it at arms length because i can't stand using it. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Reinventing the wheel
On 18/05/11 00:15, John Doty wrote: On May 17, 2011, at 7:45 AM, Russell Shaw wrote: A well-stocked workshop is nothing more than a multitool workshop. With that attitude, you'll botch the job. There's no reason why a schematic and pcb editor can't have tight coupling and still interact with all external tools. The architectures are different. To flexibly interact with external tools, you need the interfaces to be simple text files. Anything more complex is a serious barrier, in general. That's why the matching pcb/schematic editors will work seamlessly, but external tools will only work by importing and exporting file formats. If an external tool had a way of remote control by scripting, then some degree of closer coupling between the tools could be done. The only disadvantage to external tools is that an interface layer is needed. A separate piece of complex code for every interface, yes. This isn't too bad in gEDA, because we don't try to integrate the diverse collection of downstream tools with gschem: it's a pretty clean, simple flow. The coupling could simply be an ipc protocol between separate programs. Specialized IPC is good in its place. General-purpose IPC is complex, fragile, and always less flexible than intended. Agreed. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Reinventing the wheel
On 18/05/11 00:30, Stefan Salewski wrote: On Tue, 2011-05-17 at 23:59 +1000, Russell Shaw wrote: Instead of blindly reinventing the wheel, i always look in detail at what currently exists. Maybe KiCAD is a better starting point for you? Written in C++ with wxWidgets, it is available for multiple OS including windows. Here in Germany KiCad is more popular than gEDA/PCB, even for Linux users. I do not really understand this, I have never find time and motivation to really test KiCad myself. While gEDA/PCB has some serious users and a large list of projects done with gEDA, KiCAD users seems to be more childreen type, making boards with a power LED and a led driver chip... On the KiCAD developer mailing list there is much activity, but there are only a few really smart and active developers, so development progress is slow. Indeed, nearly all windows KiCAD users seems to be only consumers, without any contributions. And there is Fritzing or Qucs -- Qucs has schematics and simulation support, but PCB backend is missing. Once I had the strange idea to implement a PCB or schematics mode for inkscape. Really crazy. The problem with KiCAD is 1) C++, 2) Qt. C++ was a *really* bad idea. Qt i don't like because it was fundamentally architected just for the sake of hiding code from users using the MOC preprocessor that used to be closed source. Anyway, it's C++ too. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Reinventing the wheel
On 18/05/11 00:30, Stefan Salewski wrote: On Tue, 2011-05-17 at 23:59 +1000, Russell Shaw wrote: Instead of blindly reinventing the wheel, i always look in detail at what currently exists. Maybe KiCAD is a better starting point for you? Written in C++ with wxWidgets, it is available for multiple OS including windows. Here in Germany KiCad is more popular than gEDA/PCB, even for Linux users. I do not really understand this, I have never find time and motivation to really test KiCad myself. While gEDA/PCB has some serious users and a large list of projects done with gEDA, KiCAD users seems to be more childreen type, making boards with a power LED and a led driver chip... On the KiCAD developer mailing list there is much activity, but there are only a few really smart and active developers, so development progress is slow. Indeed, nearly all windows KiCAD users seems to be only consumers, without any contributions. And there is Fritzing or Qucs -- Qucs has schematics and simulation support, but PCB backend is missing. Once I had the strange idea to implement a PCB or schematics mode for inkscape. Really crazy. The problem with KiCAD is 1) C++, 2) Qt. C++ was a *really* bad idea. Qt i don't like because it was fundamentally architected just for the sake of hiding code from users using the MOC preprocessor that used to be closed source. Anyway, it's C++ too. If i got familiar enough with geda, i'd adapt it, but it's a tradeoff of how much work it would take compared to something new. The biggest problem is changes without affecting current users. IMO, more progress would be made by exchanging code between separate projects. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Reinventing the wheel
On 18/05/11 00:30, Stefan Salewski wrote: On Tue, 2011-05-17 at 23:59 +1000, Russell Shaw wrote: Instead of blindly reinventing the wheel, i always look in detail at what currently exists. Maybe KiCAD is a better starting point for you? Written in C++ with wxWidgets, it is available for multiple OS including windows. Here in Germany KiCad is more popular than gEDA/PCB, even for Linux users. I do not really understand this, I have never find time and motivation to really test KiCad myself. While gEDA/PCB has some serious users and a large list of projects done with gEDA, KiCAD users seems to be more childreen type, making boards with a power LED and a led driver chip... On the KiCAD developer mailing list there is much activity, but there are only a few really smart and active developers, so development progress is slow. Indeed, nearly all windows KiCAD users seems to be only consumers, without any contributions. And there is Fritzing or Qucs -- Qucs has schematics and simulation support, but PCB backend is missing. Once I had the strange idea to implement a PCB or schematics mode for inkscape. Really crazy. The problem with KiCAD is 1) C++, 2) Qt. C++ was a *really* bad idea. Qt i don't like because it was fundamentally architected just for the sake of hiding code from users using the MOC preprocessor that used to be closed source. Anyway, it's C++ too. If i got familiar enough with geda, i'd adapt it, but it's a tradeoff of how much work it would take compared to something new. The biggest problem is changes without affecting current users. IMO, more progress would be made by exchanging code between separate projects. It seems like too much redundancy to have two projects with similar uses (which i wouldn't like), and i don't like forking either. I'm still studying geda, but if i did some real work on it, it would end up having an extra file format, extra guis, and a closer sch/pcb link. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Reinventing the wheel
On 18/05/11 01:41, John Doty wrote: On May 17, 2011, at 9:06 AM, Russell Shaw wrote: It seems like too much redundancy to have two projects with similar uses (which i wouldn't like), and i don't like forking either. But your vision is an integrated tool, while gEDA is a toolkit. I'm still studying geda, but if i did some real work on it, it would end up having an extra file format, extra guis, and a closer sch/pcb link. Please, no. These are tools that represent extremely incompatible design philosophies. They work well together only because the interface is clean and simple, and avoids the minefield of integration. Most guis hide what they do. I believe in them showing the commands they send internally as a script would (or atleast have the option to show that) so the user can paste the commands into an external file if needed. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Unsubscribing from the list
On 18/05/11 02:01, Peter TB Brett wrote: Hi folks, It's no longer a worthwhile use of my time to monitor this list, due to the excessively low signal-to-noise ratio. I'm therefore unsubscribing from it for the time being. I will continue to monitor the gEDA-bug and gEDA-dev mailing lists. If you wish to get help with using gEDA, please file a question here: https://answers.launchpad.net/geda If you think you have found a bug, or wish to submit a patch, please file a report here: https://bugs.launchpad.net/geda Don't go dammit, i didn't intend posting anything more, let alone the last lot. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: pcjc2 tessellation
On 11/09/10 07:59, Peter Clifton wrote:
On Fri, 2010-09-10 at 14:16 -0400, Windell H. Oskay wrote:
On Fri, Sep 10, 2010 at 01:31:48AM +0100, Peter Clifton wrote:
PS.. have you tried any of the GL stuff?
http://www2.eng.cam.ac.uk/~pcjc2/geda/trans_poly.png
http://www2.eng.cam.ac.uk/~pcjc2/geda/pcb+gl_3d/pcb+gl_3d-1.png
http://www2.eng.cam.ac.uk/~pcjc2/geda/pcb+gl_3d/pcb+gl_3d-2.png
http://www2.eng.cam.ac.uk/~pcjc2/geda/pcb+gl_3d/pcb+gl_3d-3.png
http://www2.eng.cam.ac.uk/~pcjc2/geda/pcb+gl_3d/pcb+gl_3d-4.png
http://www2.eng.cam.ac.uk/~pcjc2/geda/pcb+gl_3d/pcb+gl_3d-5.png
http://www2.eng.cam.ac.uk/~pcjc2/geda/pcb+gl_3d/pcb+gl_3d-6.png
http://www2.eng.cam.ac.uk/~pcjc2/geda/pcb+gl_3d/pcb+gl_3d-7.png
Wow. These screenshots are incredible.
Thanks!
Please excuse my naive question, but is this something that the rest of us
can expect to see in PCB someday?
Some day.. eventually. It is a slow work in progress to get the code
clean enough to push into git HEAD. In the mean time, the branch is
before_pours in this repository:
git://repo.or.cz/geda-pcb/pcjc2.git
I've been working slowly to get the OpenGL stuff to co-exist with a
standard GDK build, but for the moment that isn't finished.
Hi,
From pcjc2/src/borast/borast-bentley-ottmann.c, i used some functions
to make a small test program to see how bo_contour_to_traps() works.
In bo_contour_to_traps(), i get num_events = contour-Count = 0,
so i must be missing something. Here's the test i was trying:
void
borast(void)
{
Vector v;
v[0] = 0;// x
v[1] = 0;// y
PLINE *contour = poly_NewContour(v);
v[0] = 1;// x
v[1] = 0;// y
VNODE *node = poly_CreateNode(v);
VNODE *after = contour-head;
poly_InclVertex(after, node);
v[0] = 1;// x
v[1] = 1;// y
VNODE *node2 = poly_CreateNode(v);
poly_InclVertex(node, node2);
borast_traps_t traps;
bo_contour_to_traps(contour, traps);
}
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcjc2 tessellation
On 16/05/11 19:26, Peter Clifton wrote:
On Mon, 2011-05-16 at 15:54 +1000, Russell Shaw wrote:
From pcjc2/src/borast/borast-bentley-ottmann.c, i used some functions
to make a small test program to see how bo_contour_to_traps() works.
The code is mostly stolen from cairo, then stripped down to a bare
minumum (e.g. doesn't deal with intersections in contours, as PCB
polygons don't have them).
Hi,
I've looked in cairo before but never much got the hang of it
in detail.
I'd be interested to know what you're working on. Please let me know if
you spot anything stupid in the borast/ code, I've not completely
cleaned the interfaces up ready for merging yet. (The abstraction
between them and PCB is not particularly clean).
I've always been interested in CAD programs and thought of making
a schematic/pcb one from scratch.
One thing i'm eternally conflicted with is relying on video-card
hardware that is closed source.
The problem with the free drivers is that when you send it polygons,
it could end up software rendering them, and you have no way of knowing
in advance if the performance will totally suck.
If you just generate pixels from scanline rendering in software,
this can be done directly from a list of arbitrarily intersecting
lines without requiring the bentley-ottmann polygon generator step.
You generate the whole window pixmap yourself and send that to the
screen.
Using this, i could avoid openGL. However, if an open hardware
accelerated openGL came along i was happy with, then i would need
to use the bentley-ottmann step to generate polygons, but i don't
understand that bit of code in detail, even though i've read the
paper. If i understood it in detail, then i could look closer at
how pcjc2 works and maybe improve something.
See suggestion inline with the code:
In bo_contour_to_traps(), i get num_events = contour-Count = 0,
so i must be missing something. Here's the test i was trying:
void
borast(void)
{
Vector v;
v[0] = 0;// x
v[1] = 0;// y
PLINE *contour = poly_NewContour(v);
v[0] = 1;// x
v[1] = 0;// y
VNODE *node = poly_CreateNode(v);
VNODE *after =contour-head;
poly_InclVertex(after, node);
v[0] = 1;// x
v[1] = 1;// y
VNODE *node2 = poly_CreateNode(v);
poly_InclVertex(node, node2);
After the last vertex in a contour, you need to finish preparing the
contour, with a call to:
poly_PreContour (contour, TRUE); /* TRUE turns optimisation for
redundant nodes on, FALSE should work too */
This calculates the contour's area, figures out what order you defined
the edges in (winding order), and constructs an r-tree of the edges (to
make the contour participate faster in boolean operations)
borast_traps_t traps;
bo_contour_to_traps(contour,traps);
}
Thanks muchly:)
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcjc2 tessellation
On 16/05/11 19:26, Peter Clifton wrote:
On Mon, 2011-05-16 at 15:54 +1000, Russell Shaw wrote:
From pcjc2/src/borast/borast-bentley-ottmann.c, i used some functions
to make a small test program to see how bo_contour_to_traps() works.
The code is mostly stolen from cairo, then stripped down to a bare
minumum (e.g. doesn't deal with intersections in contours, as PCB
polygons don't have them).
I'd be interested to know what you're working on. Please let me know if
you spot anything stupid in the borast/ code, I've not completely
cleaned the interfaces up ready for merging yet. (The abstraction
between them and PCB is not particularly clean).
Hi,
In poly_PreContour(), the sign of the winding area is found by
summing the area of each box formed by consecutive points. It is
not clear if this method is valid. Is there a reference paper?
double area = 0;
...
do {
area += (double) (p-point[0] - c-point[0]) * (p-point[1] +
c-point[1]);
}
I think better if:
int area = 0;
...
do {
area += p-point[0]*c-point[1] - c-point[0]*p-point[1];
/* http://en.wikipedia.org/wiki/Polygon#Area_and_centroid */
}
because it calculates the total winding area of a polygon.
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: client side decorations
On 11/05/11 18:55, Michal Suchanek wrote: On 10 May 2011 05:46, Russell Shawrjs...@netspace.net.au wrote: On 10/05/11 07:29, Daniel wrote: El dg 08 de 05 de 2011 a les 09:47 -0700, en/na Bill Spitzak va escriure: Though it is possible, I don't like the idea of clients sending hints about what areas are the close box or window border, since it implies there are such concepts as title bar and close box. The compositor can just have clicks anywhere raise and move the non-responsive window, and lots of clicks (indicating user frustration) pop up a box offering to kill the program. On Linux, since it is standard, compositors can also have Alt+click always raise/move windows, and alt +right click pop up a menu of compositor-side window actions. This would be actually a good way to handle it. Use an special mode or tool, a la xkill, to deal with stuck applications. It can take the form of an special key/mouse combination, gestures, or as I said before, an external tool like xkill. Note that it needs not be limited to killing, but could do any other thing, like minimizing, sending to another virtual desktop, etc. Keeping track of dead clients could be done like this: A client program opens a socket connection to the window server, and the window server determines the PID of the client via a means that the client has no control over (some kind of kernel call that can determine the client using that socket). The client also sends the window server the title bar area that contains the maximize/minimize/close buttons. All clients must handle an is_alive probe event from the window server at any time, replying with something unspecified to confirm it is not dead. Whenever the mouse is clicked in the title bar, the window server can expect the client to send it an is_alive notification within say 1 second. If it doesn't, the window server can send the client an is_alive probe event. If there's no response after a certain time, the window server can kill the client. Alternatively, it could pop up a gui task manager window for the user to manually kill stuff. Clearly it's up to the user to decide if an application is stuck or not. The is_alive request may look like a nice idea at the first glance but it is not very reliable. How long timeout is allowed before the application is marked 'unresponsive'? This is clearly application and system specific. Any timeout based protocol is inherently unreliable. In X, dragging or resizing a window is instantaneous. The proposed scheme was to allow a 1000 millisecond delay before assuming the client was stuck. It was assumed the user could also bring up a task manager with crtl-alt-delete and kill a client manually if needed. The application may have a separate thread to fulfill this is_alive requirement and the rest may still be stuck. The application may be running but in undesirable state which is not something the compositor can decide. An utility like xkill resolves all of the above. You don't like the application so you get rid of it. The compositor can resize or hide the application window at any time without any cooperation from the application. The application may publish hints as to how it wants the window content treated when it does not match the size of the displayed window and the compositor may use these to present the window in a reasonable way until the application resizes the content. This requires that the compositor notifies the application when the window is resized. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: client side decorations
On 06/05/11 10:18, Bill Spitzak wrote: I believe client-side decorations are an absolute must. The amount of code necessary for an application to use an async protocol to describe how the window border should appear is greatly larger than that needed to just draw and handle events in the window border itself. In FLTK I would estimate the ICCCM code for the window object is about 5 times larger than the code for an otherwise similar MDI-like frame where FLTK draws everything. Handling resize and other events cleanly is a real mess, too, due to the async nature of them. Also such designs lock the user interface ideas into whatever existed at that time, an excellent example is Gimp's being forced to give up any attempt to make multiple windows because of window managers failing to implement the many controls it would need. ... Any program could manage the internals of their own desktop window, acting like a sub window manager for other windows belonging to that program. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: client side decorations
On 06/05/11 10:18, Bill Spitzak wrote: I believe client-side decorations are an absolute must. The amount of code necessary for an application to use an async protocol to describe how the window border should appear is greatly larger than that needed to just draw and handle events in the window border itself. In FLTK I would estimate the ICCCM code for the window object is about 5 times larger than the code for an otherwise similar MDI-like frame where FLTK draws everything. Handling resize and other events cleanly is a real mess, too, due to the async nature of them. Also such designs lock the user interface ideas into whatever existed at that time, an excellent example is Gimp's being forced to give up any attempt to make multiple windows because of window managers failing to implement the many controls it would need. ... Any program could manage the internals of their own desktop window, acting like a sub window manager for other windows belonging to that program. The program would need to draw its own maximize/minimize/close buttons. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: debbugs, and a FAQ, for Autotools
On 20/02/11 06:10, Ralf Wildenhues wrote:
Hi Russell,
* Russell Shaw wrote on Mon, Feb 14, 2011 at 12:00:14AM CET:
I'd ask more about how the internals of ./configure and autoconf works.
Can you formulate more specific questions?
And questions on how to make bison get handled without being forced to
mimic standard yacc.
I've added that question there now (without answer so far).
Thanks,
Ralf
Hi,
I'm not in autoconf debugging mode atm, so i'll have to ask more detailed
things some other time.
Looking through a ./configure script, i see lots of things being done
with file descriptors 5 and 6. What is going on here? eg:
## ##
## Autoconf initialization. ##
## ##
# ac_fn_c_try_compile LINENO
# --
# Try to compile conftest.$ac_ext, and return whether this succeeded.
ac_fn_c_try_compile ()
{
as_lineno=${as_lineno-$1} as_lineno_stack=as_lineno_stack=$as_lineno_stack
rm -f conftest.$ac_objext
if { { ac_try=$ac_compile
case (($ac_try in
*\* | *\`* | *\\*) ac_try_echo=\$ac_try;;
*) ac_try_echo=$ac_try;;
esac
eval ac_try_echo=\\$as_me:${as_lineno-$LINENO}: $ac_try_echo\
$as_echo $ac_try_echo; } 5
(eval $ac_compile) 2conftest.err
ac_status=$?
if test -s conftest.err; then
grep -v '^ *+' conftest.err conftest.er1
cat conftest.er1 5
mv -f conftest.er1 conftest.err
fi
$as_echo $as_me:${as_lineno-$LINENO}: \$? = $ac_status 5
test $ac_status = 0; } {
test -z $ac_c_werror_flag ||
test ! -s conftest.err
} test -s conftest.$ac_objext; then :
ac_retval=0
else
$as_echo $as_me: failed program was: 5
sed 's/^/| /' conftest.$ac_ext 5
ac_retval=1
fi
eval $as_lineno_stack; test x$as_lineno_stack = x { as_lineno=; unset
as_lineno;}
as_fn_set_status $ac_retval
} # ac_fn_c_try_compile
Re: debbugs, and a FAQ, for Autotools
On 14/02/11 05:12, Ralf Wildenhues wrote: [ Cross post; Reply-To and Mail-Followup-To set. Please followup to the automake list only, to avoid excessive spammage. Thank you. ] Hello everyone, I've been advertising debbugs before, I think we should be a good example. So, two proposals: 1) Autoconf and Libtool should also use debbugs. bug-automake has switched a few months ago, and I find it helpful to avoid losing reports. Given that we never have enough time on our hands, it becomes more important to not lose track. See http://debbugs.gnu.org/ and linked pages for details. 2) Autotools should have a FAQ document. Not of the sort of the FAQ chapter that answers seven random questions and that has a 1 year+ latency until it is updated, but one that answers both totally-newbie kinds of questions that get asked over and over again, or cross-tool bug questions like the infamous libtool echo problem (which was due to an incompatible m4sugar change). A document that, ideally, eventually obsoletes many of the third-party here's how autotools work, in quick kinds of pages. See e.g., this most recent thread which made the need so clear again: http://thread.gmane.org/gmane.comp.sysutils.automake.patches/5672 For (2) I'd suggest a wiki if we GNU the infrastructure, but something like a new page http://www.gnu.org/software/automake/Autotools-FAQ.html would certainly be good. (And yes, I've been arguing against wikis in the past. I was wrong. Sue me.) Now, I have very little spare time on my hands. Any volunteers on managing such a document? Any people interested in contributing answers or even only questions? I wouldn't mind handing out commit privs to any of the regulars on these lists. I'd ask more about how the internals of ./configure and autoconf works. And questions on how to make bison get handled without being forced to mimic standard yacc. I'm not in the mode of autoconf hacking atm though.
Re: configure -C by default?
On 07/02/11 23:45, Brian Gough wrote: At Sun, 6 Feb 2011 23:11:43 +0100, Ralf Wildenhues wrote: Back then, the consensus was to not make it the default because that was deemed too dangerous for users. Various reports are cited, and also the problem is mentioned that such kinds of failures tend to be quiet very often and are hard to debug. The reports are convincing for me that it would be bad to revive the old behaviour. Most of the GNU maintainers at FOSDEM didn't know about the -C option though. Maybe it would help to publicise -C in the output so people are more aware of it. e.g. $ ./configure configure: not caching test results (use -C to enable) checking for a BSD-compatible install... /usr/bin/install -c ... The message could be suppressed if config.status does not exist, so it's only shown if someone is configuring more than once. If you compile/install a program successfully, then apt-get remove a library (or stuff gets uninstalled when installing something else), then the manually compiled program doesn't run. A new ./configure will run successfully from the cached results even though a required library is missing. Seems pretty bad to me if using cached results is the default. Only developers doing repeated ./configure need it, and can just use the -C option. ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Bison
Hi, On debian, there is /usr/bin/bison, and /usr/bin/bison.yacc just does: exec '/usr/bin/bison' -y $@ How can i get autoconf to use bison? The problem with yacc is that you can't rename the output files and always get: y.tab.h y.tab.c Is there a way i can get yacc to give better output file names like myproj.tab.h myproj.tab.c ? ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: Bison
On 12/01/11 06:24, John Calcote wrote: On 01/11/2011 04:31 AM, Russell Shaw wrote: Hi, On debian, there is /usr/bin/bison, and /usr/bin/bison.yacc just does: exec '/usr/bin/bison' -y $@ How can i get autoconf to use bison? The problem with yacc is that you can't rename the output files and always get: y.tab.h y.tab.c Is there a way i can get yacc to give better output file names like myproj.tab.h myproj.tab.c ? Hi Russell - try the techniques listed here: http://www.mail-archive.com/help-bison@gnu.org/msg01897.html Hi J.C, It's close to what i'm looking for, but not complete enough. I'm not good at autoconf stuff. Why is descriptor 5 used? ac_compile_yacc='$CC -c $CFLAGS $CPPFLAGS $ac_cv_prog_yacc_root.c 5' ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: gEDA-user: gEDA Wikibook ?
On 26/12/10 01:13, Karl Hammar wrote: Russell: ... I don't do latex, because not one sane person on any planet can explain Tex. (yes, i've read all the tex manuals and have written compiler tools) Strange wording. I've not read the tex manuals and I can still produce and be fluent with Latex. About Tex, it's just an old macro processor and as such it has it's drawbacks. The good point (depending of your point of view) about Tex is that it's format is stable, you don't have to relearn every tree years. Hi, I've written documents with images in Latex. It all seems quite neat on the surface. When you dig down to Tex to try and do something for templates other than book or article, there's no hope in hell in making sense of the incoherent ramblings of all the existing Tex documentation. The most technical terms for the parsing machinery is throat/gullet/stomach. Where is the BNF syntax for the Tex parser, or the list of recognized characters for the recognized keywords? Where is the list of builtin functions for any builtin keywords? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Small patch to aid use of lib dmalloc
On 07/12/10 11:55, Peter Clifton wrote: On Tue, 2010-12-07 at 00:48 +, Peter Clifton wrote: On Tue, 2010-12-07 at 10:04 +1100, Stephen Ecob wrote: Dropping the (a) ? (a) : 1 foolishness would be cleaner, but could expose latent bugs in the 71 callers of the mymem allocators. I'm happy to proceed either way. What is your preference ? Let me push a big patch nuking the My* allocation functions, that would make me feel much happier. Damnit, MyMalloc does some other helpful things, like checking for a memory allocation failure and aborting with a useful diagnostic message. I'd be pretty happy to drop the messages (as it is not such a common occurrence), but I do note that the changes I'm about to propose will change a known handled failure path with a nice error message and termination, to retuning a NULL pointer which is then probably used, probably followed by segfault. On Linux at least, malloc will tend to always succeed rather than returning out of memory. You could wrap malloc so that it does a longjmp to the start of the program where the error is displayed then exits. Gracefully handling malloc failures is too tedious and itself bug-prone, so just design the program so that they should never happen, given an adequte amount of memory. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: default -g ??!?
On 20/11/10 06:10, MK wrote: I have a FOSS project distributed by debian, and for quite I've been using this in the Makefile.am under install-data-am: -strip --strip-all $(bindir)/executable Since I could not find a way to prevent the project being built -g, and there is no need for this. Use dh_strip However, I have a new release and my packager at debian is now saying they do not want strip used in makefiles. How can I prevent -g from being used? The normal debian packages are stripped by dh_strip, or not when the debug-symbols debs are made. Therefore, the debian packager wants control over that. Therefore, you don't need to worry about stripping.
Re: gEDA-user: STEP Format? [WAS: Re: PCB+GL+3D Packages??]
On 20/11/10 10:02, Peter Clifton wrote: On Fri, 2010-11-19 at 13:06 -0800, Colin D Bennett wrote: That suits me just fine.. OpenGL _likes_ rendering triangles, and any other geometry primitives are extra work to implement ;) But wouldn't support for higher-level shapes be superior to triangle meshes for high-quality renderings (e.g., raytracing, etc.)? Is the goal for PCB 3D support intended to be primarily for high-quality renderings or for real-time viewing of and interaction with the 3D scene? Primarily for the latter (at the moment). I imagine your component design workflow is: Proper 3D CAD (e.g.insert cad program here) - or | | 3D graphics (e.g. Blender) | | | | | | \|/ | | Export VRML / Collada / ... for PCB's library| \|/ | |Export CAD constraints, case etc.. \|/ | Design board using PCB || | - Emit rendering description in graphics friendly format --- \|/ | | Emit board shape / component placement as CAD data in some format | | | \|/ | Render board in graphics app. \|/ povtrace / blender? Model board in CAD, design casing around it / whatever I'm coming round to the idea that 3D is more than just eye candy if we do it nicely. It helps visualise component placement and layout issues far more readily than just looking at flat layers can do. Your brain may spot issues it wouldn't otherwise. I have also spoken to design professionals who value the ability to emit 3D renderings, however rough, as it allows better communication of project progress and design ideas to clients, who may not themselves be technical. (Think.. your manager??) triangle meshes: cylindrical resistors, disc-shaped ceramic capacitors, My shiny through hole resistor screen-shots had approx 6000 panels, and yes, it does slow things down if you have lots on screen at once! Are you using a spatial data structure to omit emitting polygons for off-screen components? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: STEP Format? [WAS: Re: PCB+GL+3D Packages??]
On 20/11/10 11:43, kai-martin knaak wrote: John Griessen wrote: STL seems to work fine for those shapes - your tool just chooses triangles that are long and skinny to accurately model the side of a cylinder for instance. ... and the file size explodes. If the wires of thru hole components are supposed to look vaguely realistic on zoom, at least 20 triangles per cylinder are needed. The 90° bend needs another 40 triangles. Every triangle requires 3 nodes and every node includes three coordinates plus orientation. That way, the stl size of a simple resistor may easily xceed the memory footprint of its footprint by two orders of magnitude. You need lots of polygons for smooth shading only if the polygons are flat-shaded. If fewer polygons are used but with decent shading, the main effect is that the silhouette has a few visible corners. That wouldn't matter much for resistors. http://en.wikipedia.org/wiki/Gouraud_shading http://en.wikipedia.org/wiki/Phong_shading The other formats are wanted just for interoperability and translation. VRML might do fine for that. VRML is very similar to STL in that both are formats to export from 3D CAD applications to rendering software like blender. They both communicate just meshes, no objects. Beause of this, they are they are less useful as imports for 3D editing. From mechanical point of view these mesh formats are one-way roads. ---)kaimartin(--- ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: [openobex-users] Nokia 6120
On 16/11/10 20:06, Hendrik Sattler wrote: obexftp -H -U none -u 1 -X sudo obexftp -H -U none -u 1 -X Suppressing FBS. obexftp_open() obexftp_connect_src() Connecting...obexftp_connect_src() obexftp_connect_src() USB 1 cli_sync_request() \obexftp_sync() obexftp_sync() OBEX_HandleInput = 0 obexftp_sync() OBEX_HandleInput error: 11 failed: send UUID Tried to connect for 33ms unknown error on connect Still trying to connect obexftp_connect_src() Connecting...obexftp_connect_src() obexftp_connect_src() USB -16 failed: connect Tried to connect for 3ms unknown error on connect Still trying to connect obexftp_connect_src() Connecting...obexftp_connect_src() obexftp_connect_src() USB -16 failed: connect Tried to connect for 3ms unknown error on connect Still trying to connect obexftp_close() -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev ___ Openobex-users mailing list Openobex-users@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/openobex-users
Re: [openobex-users] Nokia 6120
On 13/11/10 03:48, Christian Zuckschwerdt wrote: Russell, you need openobex-dev (or install openobex from source) when compiling obexftp. Also you need to check that bluetooth is enabled during openobex configuration. ObexFTP has a very limited pseudo xml-parser for the directory listings. I guess the xml from the phone is somewhat non-standard. I'd be great if you could capture the output -- compile ObexFTP with debug enabled and just list/get some directories. Am 12.11.2010 um 17:26 schrieb Russell Shaw: When i mount the 6120 (not 2162), i get a heap of question-marks: sudo obexfs -t /dev/Nokia -u 1 /phone russ...@main~: ls -l / ls: cannot access /phone: Permission denied total 116 drwxr-xr-x 2 root root 4096 Nov 3 23:05 bin drwxr-xr-x 3 root root 4096 Nov 12 18:26 boot ... d? ? ?? ?? phone I try to compile obexftp-0.22 but get: obexftpd.c:891: warning: implicit declaration of function 'BtOBEX_ServerRegister' Hi, I used obexftp from http://www.gitorious.org/obexftp/mainline/ obexftp -t /dev/ttyACM1 -v -l obexftp_open() obexftp_connect_src() Connecting...cobex_connect() bfb_io_open() Checking for transparent OBEX mode Write ok, reading back bfb_io_read() No data (timeout: 2) do_at_cmd() Sending 4: ATZ bfb_io_read() No data (timeout: 2) do_at_cmd() tmpbuf=0: Comm-error or already in BFB mode do_at_cmd() Sending 4: ATZ bfb_io_read() No data (timeout: 2) do_at_cmd() tmpbuf=0: Comm-error or already in BFB mode bfb_write_packets() Select failed bfb_io_init() Wrote -1 packets BFB port error bfb_write_packets() Select failed bfb_io_init() Wrote -1 packets BFB port error Couldn't init BFB mode. bfb_io_close() -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev ___ Openobex-users mailing list Openobex-users@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/openobex-users
Re: [openobex-users] Nokia 6120
On 14/11/10 21:25, Russell Shaw wrote: On 13/11/10 23:56, Christian Zuckschwerdt wrote: Russel, just remove doc from Makefile.am, then run autoreconf. Or even simpler touch doc/obexftp.1. Am 13.11.2010 um 03:34 schrieb Russell Shaw: I got obexftp from git. I get a doc error: ./configure CFLAGS=-DOBEXFTP_DEBUG=5 -g -O0 make[2]: Entering directory `/home/russell/SRC/obexftp/doc' make[2]: *** No rule to make target `obexftp.1', needed by `all-am'. Stop. Hi, I tried compiling openobex from git. In openobex/apps/obex_test, i type make: make: *** No rule to make target `/../lib/libmisc.a', needed by `obex_test'. Stop. I think it's because builddir is not defined anywhere in Makefile. It should be defined as '.' This causes problems, because the automake manual says: — Variable: builddir Rigorously equal to ‘.’. Added for symmetry only. Hi, I had a closer look at my system and found the debian alternatives system was pointing at an old version of automake. I set it right now. -- Centralized Desktop Delivery: Dell and VMware Reference Architecture Simplifying enterprise desktop deployment and management using Dell EqualLogic storage and VMware View: A highly scalable, end-to-end client virtualization framework. Read more! http://p.sf.net/sfu/dell-eql-dev2dev ___ Openobex-users mailing list Openobex-users@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/openobex-users
Re: [openobex-users] Nokia 6120
On 13/11/10 23:56, Christian Zuckschwerdt wrote:
Russel,
just remove doc from Makefile.am, then run autoreconf. Or even simpler
touch doc/obexftp.1.
Am 13.11.2010 um 03:34 schrieb Russell Shaw:
I got obexftp from git. I get a doc error:
./configure CFLAGS=-DOBEXFTP_DEBUG=5 -g -O0
make[2]: Entering directory `/home/russell/SRC/obexftp/doc'
make[2]: *** No rule to make target `obexftp.1', needed by `all-am'. Stop.
Hi,
I compiled and installed openobex from git. I then tried compiling obexftp
from git:
make all-recursive
make[1]: Entering directory `/home/russell/SRC/obexftp'
Making all in bfb
make[2]: Entering directory `/home/russell/SRC/obexftp/bfb'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/russell/SRC/obexftp/bfb'
Making all in multicobex
make[2]: Entering directory `/home/russell/SRC/obexftp/multicobex'
if /bin/bash ../libtool --tag=CC --mode=compile /usr/bin/gcc -DHAVE_CONFIG_H
-I.
-I. -I..-I/usr/local/include -I.. -I../includes -DOBEXFTP_DEBUG=5 -g -O0 -W
-Wundef -Wmissing-declarations -Wmissing-prototypes -Wall -MT multi_cobex.lo
-MD
-MP -MF .deps/multi_cobex.Tpo -c -o multi_cobex.lo multi_cobex.c; \
then mv -f .deps/multi_cobex.Tpo .deps/multi_cobex.Plo; else rm -f
.deps/multi_cobex.Tpo; exit 1; fi
libtool: compile: /usr/bin/gcc -DHAVE_CONFIG_H -I. -I. -I..
-I/usr/local/include -I.. -I../includes -DOBEXFTP_DEBUG=5 -g -O0 -W -Wundef
-Wmissing-declarations -Wmissing-prototypes -Wall -MT multi_cobex.lo -MD -MP
-MF
.deps/multi_cobex.Tpo -c multi_cobex.c -fPIC -DPIC -o .libs/multi_cobex.o
multi_cobex.c: In function 'cobex_cleanup':
multi_cobex.c:74: warning: pointer targets in passing argument 3 of
'bfb_write_packets' differ in signedness
../bfb/bfb.h:90: note: expected 'uint8_t *' but argument is of type 'char *'
multi_cobex.c:76: warning: pointer targets in passing argument 2 of
'bfb_io_write' differ in signedness
../bfb/bfb_io.h:41: note: expected 'const uint8_t *' but argument is of type
'char *'
multi_cobex.c:78: warning: pointer targets in passing argument 2 of
'bfb_io_write' differ in signedness
../bfb/bfb_io.h:41: note: expected 'const uint8_t *' but argument is of type
'char *'
libtool: compile: /usr/bin/gcc -DHAVE_CONFIG_H -I. -I. -I..
-I/usr/local/include -I.. -I../includes -DOBEXFTP_DEBUG=5 -g -O0 -W -Wundef
-Wmissing-declarations -Wmissing-prototypes -Wall -MT multi_cobex.lo -MD -MP
-MF
.deps/multi_cobex.Tpo -c multi_cobex.c -o multi_cobex.o /dev/null 21
/bin/bash ../libtool --tag=CC --mode=link /usr/bin/gcc -I/usr/local/include
-I..
-I../includes -DOBEXFTP_DEBUG=5 -g -O0 -W -Wundef -Wmissing-declarations
-Wmissing-prototypes -Wall -o libmulticobex.la -rpath /usr/local/lib
-no-undefined -version-info 1\:1\:0 multi_cobex.lo -L/usr/local/lib -lopenobex
../bfb/libbfb.la
libtool: link: rm -fr .libs/libmulticobex.a .libs/libmulticobex.la
.libs/libmulticobex.lai .libs/libmulticobex.so .libs/libmulticobex.so.1
.libs/libmulticobex.so.1.0.1
libtool: link: /usr/bin/gcc -shared .libs/multi_cobex.o -Wl,-rpath
-Wl,/home/russell/SRC/obexftp/bfb/.libs -L/usr/local/lib
/usr/local/lib/libopenobex.so ../bfb/.libs/libbfb.so-Wl,-soname
-Wl,libmulticobex.so.1 -o .libs/libmulticobex.so.1.0.1
libtool: link: (cd .libs rm -f libmulticobex.so.1 ln -s
libmulticobex.so.1.0.1 libmulticobex.so.1)
libtool: link: (cd .libs rm -f libmulticobex.so ln -s
libmulticobex.so.1.0.1 libmulticobex.so)
libtool: link: ar cru .libs/libmulticobex.a multi_cobex.o
libtool: link: ranlib .libs/libmulticobex.a
libtool: link: ( cd .libs rm -f libmulticobex.la ln -s
../libmulticobex.la libmulticobex.la )
make[2]: Leaving directory `/home/russell/SRC/obexftp/multicobex'
Making all in obexftp
make[2]: Entering directory `/home/russell/SRC/obexftp/obexftp'
if /bin/bash ../libtool --tag=CC --mode=compile /usr/bin/gcc -DHAVE_CONFIG_H
-I.
-I. -I..-I/usr/local/include -I.. -I../includes -DOBEXFTP_DEBUG=5 -g -O0 -W
-Wundef -Wmissing-declarations -Wmissing-prototypes -Wall -MT object.lo -MD -MP
-MF .deps/object.Tpo -c -o object.lo object.c; \
then mv -f .deps/object.Tpo .deps/object.Plo; else rm -f
.deps/object.Tpo; exit 1; fi
libtool: compile: /usr/bin/gcc -DHAVE_CONFIG_H -I. -I. -I..
-I/usr/local/include -I.. -I../includes -DOBEXFTP_DEBUG=5 -g -O0 -W -Wundef
-Wmissing-declarations -Wmissing-prototypes -Wall -MT object.lo -MD -MP -MF
.deps/object.Tpo -c object.c -fPIC -DPIC -o .libs/object.o
object.c:39: error: parameter 1 ('obex') has incomplete type
object.c: In function 'obexftp_build_info':
object.c:39: warning: unused parameter 'obex'
object.c: At top level:
object.c:73: error: parameter 1 ('obex') has incomplete type
object.c: In function 'obexftp_build_get':
object.c:73: warning: unused parameter 'obex'
object.c: At top level:
object.c:125: error: parameter 1 ('obex') has incomplete type
object.c: In function 'obexftp_build_rename':
object.c:125: warning: unused parameter 'obex'
object.c: At top level:
object.c
Re: builddir
On 15/11/10 01:10, Ralf Wildenhues wrote: Hello Russell, * Russell Shaw wrote on Sun, Nov 14, 2010 at 02:49:07AM CET: In a Makefile.in generated by automake 1.9.6, it defines top_builddir ok, but builddir is used but not defined in there. This causes problems, because the automake manual says: — Variable: builddir Rigorously equal to ‘.’. Added for symmetry only. Automake 1.9.6 is very old. Presumably you're using an ancient version of Autoconf too, please state which. Normally I'd say upgrade and retry, but I might look at this if you post a small reproducer. Hi, I had a closer look at my system and found the debian alternatives system was pointing at an old version. I set it right now thanks.
builddir
Hi, In a Makefile.in generated by automake 1.9.6, it defines top_builddir ok, but builddir is used but not defined in there. This causes problems, because the automake manual says: — Variable: builddir Rigorously equal to ‘.’. Added for symmetry only.
[openobex-users] Nokia 2162
Hi, When i mount the 2162, i get a heap of question-marks: sudo obexfs -t /dev/Nokia -u 1 /phone russ...@main~: ls -l / ls: cannot access /phone: Permission denied total 116 drwxr-xr-x 2 root root 4096 Nov 3 23:05 bin drwxr-xr-x 3 root root 4096 Nov 12 18:26 boot ... d? ? ?? ?? phone I try to compile obexftp-0.22 but get: russ...@main~/SRC/obexftp-0.22: make make all-recursive make[1]: Entering directory `/home/russell/SRC/obexftp-0.22' Making all in bfb make[2]: Entering directory `/home/russell/SRC/obexftp-0.22/bfb' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/home/russell/SRC/obexftp-0.22/bfb' Making all in multicobex make[2]: Entering directory `/home/russell/SRC/obexftp-0.22/multicobex' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/home/russell/SRC/obexftp-0.22/multicobex' Making all in obexftp make[2]: Entering directory `/home/russell/SRC/obexftp-0.22/obexftp' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/home/russell/SRC/obexftp-0.22/obexftp' Making all in apps make[2]: Entering directory `/home/russell/SRC/obexftp-0.22/apps' if /usr/bin/gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../includes -DOBEXFTP_DEBUG=5 -g -O0 -W -Wundef -Wmissing-declarations -Wmissing-prototypes -Wall -MT obexftpd.o -MD -MP -MF .deps/obexftpd.Tpo -c -o obexftpd.o obexftpd.c; \ then mv -f .deps/obexftpd.Tpo .deps/obexftpd.Po; else rm -f .deps/obexftpd.Tpo; exit 1; fi obexftpd.c:81: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token obexftpd.c: In function 'start_server': obexftpd.c:891: warning: implicit declaration of function 'BtOBEX_ServerRegister' obexftpd.c:891: error: 'bt_src' undeclared (first use in this function) obexftpd.c:891: error: (Each undeclared identifier is reported only once obexftpd.c:891: error: for each function it appears in.) make[2]: *** [obexftpd.o] Error 1 make[2]: Leaving directory `/home/russell/SRC/obexftp-0.22/apps' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/russell/SRC/obexftp-0.22' make: *** [all] Error 2 -- Centralized Desktop Delivery: Dell and VMware Reference Architecture Simplifying enterprise desktop deployment and management using Dell EqualLogic storage and VMware View: A highly scalable, end-to-end client virtualization framework. Read more! http://p.sf.net/sfu/dell-eql-dev2dev ___ Openobex-users mailing list Openobex-users@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/openobex-users
[openobex-users] Nokia 6120
Hi, When i mount the 6120 (not 2162), i get a heap of question-marks: sudo obexfs -t /dev/Nokia -u 1 /phone russ...@main~: ls -l / ls: cannot access /phone: Permission denied total 116 drwxr-xr-x 2 root root 4096 Nov 3 23:05 bin drwxr-xr-x 3 root root 4096 Nov 12 18:26 boot ... d? ? ?? ?? phone I try to compile obexftp-0.22 but get: russ...@main~/SRC/obexftp-0.22: make make all-recursive make[1]: Entering directory `/home/russell/SRC/obexftp-0.22' Making all in bfb make[2]: Entering directory `/home/russell/SRC/obexftp-0.22/bfb' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/home/russell/SRC/obexftp-0.22/bfb' Making all in multicobex make[2]: Entering directory `/home/russell/SRC/obexftp-0.22/multicobex' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/home/russell/SRC/obexftp-0.22/multicobex' Making all in obexftp make[2]: Entering directory `/home/russell/SRC/obexftp-0.22/obexftp' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/home/russell/SRC/obexftp-0.22/obexftp' Making all in apps make[2]: Entering directory `/home/russell/SRC/obexftp-0.22/apps' if /usr/bin/gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../includes -DOBEXFTP_DEBUG=5 -g -O0 -W -Wundef -Wmissing-declarations -Wmissing-prototypes -Wall -MT obexftpd.o -MD -MP -MF .deps/obexftpd.Tpo -c -o obexftpd.o obexftpd.c; \ then mv -f .deps/obexftpd.Tpo .deps/obexftpd.Po; else rm -f .deps/obexftpd.Tpo; exit 1; fi obexftpd.c:81: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token obexftpd.c: In function 'start_server': obexftpd.c:891: warning: implicit declaration of function 'BtOBEX_ServerRegister' obexftpd.c:891: error: 'bt_src' undeclared (first use in this function) obexftpd.c:891: error: (Each undeclared identifier is reported only once obexftpd.c:891: error: for each function it appears in.) make[2]: *** [obexftpd.o] Error 1 make[2]: Leaving directory `/home/russell/SRC/obexftp-0.22/apps' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/russell/SRC/obexftp-0.22' make: *** [all] Error 2 -- Centralized Desktop Delivery: Dell and VMware Reference Architecture Simplifying enterprise desktop deployment and management using Dell EqualLogic storage and VMware View: A highly scalable, end-to-end client virtualization framework. Read more! http://p.sf.net/sfu/dell-eql-dev2dev ___ Openobex-users mailing list Openobex-users@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/openobex-users
Re: [Mesa-dev] Dri api
On 11/11/10 01:36, Jerome Glisse wrote: On Wed, Nov 10, 2010 at 2:36 AM, Russell Shawrjs...@netspace.net.au wrote: Hi, I compiled mesa from sources. In mesa/src/driclient/src/XF86dri.c, if i use the api to make a drawable, how can i find the buffer pixel format? See my other reply on the wayland mailing list but i think you are trying to achieve somethings that we could not recommand. As i already said dri is intented to be an api btw 2 part of the same driver, at no time it was designed to allocate buffer for general use and there is no way to allocate buffer in hw independant maner. If you really would like to be able to do direct pixel banging on buffer that can the be use by the GPU (i guess use case here is for wayland) i think you would need to build a library that can provide an API and have backend for each GPU we care about (amd,intel,nvidia). Such library could be an add on to the drm one and likely leave in the same repository. Hi, I can do all the openVG/GL stuff without a gpu. Because there is an ever increasing number of embedded micros with GPUs, there is less need to emulate a GPU-less system. Therefore, i'll increase my minimum requirements. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Dri2 buffer format
Hi,
How should the format of a DRI2 buffer be determined?
http://www.x.org/releases/current/doc/dri2proto/dri2proto.txt
DRI2ATTACH_FORMAT { attachment: CARD32
format: CARD32 }
The DRI2ATTACH_FORMAT describes an attachment and the associated
format. 'attachment' describes the attachment point for the buffer,
'format' describes an opaque, device-dependent format for the buffer.
xorg-server-1.7.7/hw/xfree86/dri2/dri2ext.c
If it's opaque, how does a user or library know what bytes are red/green/blue
so that you can draw a line in the right colour?
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com
[Mesa-dev] X Dri
Hi,
How should the format of a DRI2 buffer be determined?
http://www.x.org/releases/current/doc/dri2proto/dri2proto.txt
DRI2ATTACH_FORMAT { attachment: CARD32
format: CARD32 }
The DRI2ATTACH_FORMAT describes an attachment and the associated
format. 'attachment' describes the attachment point for the buffer,
'format' describes an opaque, device-dependent format for the buffer.
xorg-server-1.7.7/hw/xfree86/dri2/dri2ext.c
If it's opaque, how does a user or library know what bytes are red/green/blue
so that you can draw a line in the right colour?
I want to bit-bang pixels in an X app on the local machine, without any
intervening GL drivers.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Dri2 buffer format
Hi,
How should the format of a DRI2 buffer be determined?
http://www.x.org/releases/current/doc/dri2proto/dri2proto.txt
DRI2ATTACH_FORMAT { attachment: CARD32
format: CARD32 }
The DRI2ATTACH_FORMAT describes an attachment and the associated
format. 'attachment' describes the attachment point for the buffer,
'format' describes an opaque, device-dependent format for the buffer.
xorg-server-1.7.7/hw/xfree86/dri2/dri2ext.c
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: XInput
On 05/11/10 10:21, Peter Hutterer wrote: On Thu, Nov 04, 2010 at 10:35:29PM +1100, Russell Shaw wrote: In XInput2, when i get a XI_HierarchyChanged event after plugging in another mouse, is there a way to get a unique identifier for each device such as a brand and model number? no, the device ID is unfortunately the only identifier you have. model/vendor information, etc. isn't exported by any driver yet. Cheers, Peter When i start my program that uses two mice for different functions (one in each hand), it would be useful for them both to be assigned the correct role whenever the program is started, regardless of whatever other devices have been plugged in since the last session. Hi, A unique ID would be useful. I found this in linux-2.6.31.1/drivers/input/evdev.c: if (_IOC_NR(cmd) == _IOC_NR(EVIOCGUNIQ(0))) return str_to_user(dev-uniq, _IOC_SIZE(cmd), p); It was not clear how to integrate it in to xf86-input-evdev/src/evdev.c When i start a program that uses a left-hand puck (i'm using a mouse) and a normal right-hand mouse, i'll have to make a pop-up widget appear every time so that the user can choose which mouse does what. It would be good if the application can store the settings for a unique device id. I used to use this mouse and puck arrangement around 1990 on a Human Interface Loop Bus (HIL Bus) on a HP 9000 Apollo workstation. It was a standard way of running CAD programs and greatly reduced mouse-finger fatigue. The software was killed for political reasons, but the useability was far better than the toy Windows stuff around now. http://wiki.parisc-linux.org/HIL ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Slow Radeon on upgrade
Justin P. Mattock wrote: On 11/02/2010 10:42 PM, Russell Shaw wrote: I commented out all of xorg.conf, but it didn't fix it. maybe try the ati driver instead of the radeonhd? Hi, I messed around with xorg.conf settings and tried reinstalling the old driver and xorg-core resulting in a locked pc at bootup. After unsetting various things and rinstalling stuff, i just got it to boot up with the new xorg and driver and now everything's running fast. Don't know what caused that. ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Slow Radeon on upgrade
I commented out all of xorg.conf, but it didn't fix it. ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: How to properly use XGrabKey to get a program hotkey
cheshirekow wrote: Hello, My goal is to have a program that sleeps in the background but can be activated by the user via some hotkey. From digging around the Xlib manual and the Xlib O'reilly manual, I gather that the correct way to to this is with XGrabKey. However my understanding of the process is incorrect as a simple proof of concept does not work. My understanding is that if I call XGrabKey with the root window as the grab_window, and owner_events false, then whenever my hotkey is pressed the event will be sent *only* to the root window. If I then select KeyPress events from the root window, and then listen for X events, I should get a key press event when the hotkey is pressed. I've pasted a minimal example below. What I expect is that when the program is run, regardless of what window has focus, if Ctrl+Shift+K is pressed, my program should output Hot key pressed! in the console, and then terminate. Furthermore, it is my understanding that if the XGrabKey fails, the default error handler will display a message, and since it does not I am assuming that the call succeeds. Obviously, my understanding is flawed somehow. Can anyone point me in the right direction? This will only work if the window manager or the window with focus doesn't already grab the same keys. Does the example work without a window manager running? ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: gEDA-user: new footprint guidelines
John Doty wrote: On Oct 1, 2010, at 3:55 PM, Rick Collins wrote: Oh, I almost forgot, NEVER ask a PhD anything to design PCBs. What the heck are you thinking??? Speaking as a physicist, let me comment. 1. Learning to do a variety of engineering tasks is an important part of an experimental physicist's education. A good experimental physicist must be a more versatile engineer than most engineering specialists. This is exactly the kind of job a Ph.D. student *should* be doing. 2. The specific problem mentioned was a super noiseless detector circuit. Few EE's understand detector physics or noise physics well enough to tackle this. Most PHDs when challenged to do something outside of a pretty narrow field, might as well be qualified as a Post-Hole Digger. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: AC_CACHE_CHECK
Thomas Dickey wrote: On Sun, 5 Sep 2010, Russell Shaw wrote: Hi, When should AC_CACHE_CHECK be used? Whenever the user uninstalls something, wouldn't the cache become invalid? ...only if the user happened to uninstall something during the configure process. After that, AC_CACHE_CHECK is irrelevant. But if the user uninstalls libfoo then later re-runs ./configure, won't libfoo still be assumed to be installed? ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
AC_CACHE_CHECK
Hi, When should AC_CACHE_CHECK be used? Whenever the user uninstalls something, wouldn't the cache become invalid? ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: gEDA-user: wishful UI
Andrew Poelstra wrote: I've been learning the code base and testing out new ideas, and it looks like I'll have to change the base HID code to support layer groups. So there's some more design work to run by you guys before I can do any real work: My vision is this: the current drawing area will become a tabbed drawing area, with each tab a different Group. Each Group is a logically connected subset of the PCB - so for example, you might have a power supply Group, a USB port Group, an amplifier Group, etc. Each Group can span multiple physical layers. The first Group is the All Group, that encompasses the entire PCB. It cannot be deleted. This simplifies the design and also means that if you don't use the Grouping feature at all, your workflow will be exactly the same as it always was. I hope to use Cairo to draw the viewport, and make the non-current Groups' components display as semi-transparent. Also, you will be able to open individual elements in their own Group, as well as open/save/edit them as such. This eliminates the awkward buffer manipulations that are currently needed to work on elements. Ignoring the All Group, the following things should be set on a per-Group basis: o Group Name o Group-specific routing styles o Visible physical layers o Active physical layer/routing style o DRC rules (?) o Undo/Redo buffer (?) The following should be set globally: o PCB name, board size, etc. o Physical layers (numbers, names, colors) o Global routing styles That's what I've got now. What you you guys think? Should have a left-hand panel tree view of the files in a project: http://en.wikipedia.org/wiki/Tree_view ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: Autotools book published
John Calcote wrote: Hi all. Just a quick note to let you all know that my Autotools book has been published (finally!) by No Starch Press: http://nostarch.com/autotools.htm I apologize in advance for the apparent self-promoting tone of this message but I know there are folks out there interested in hearing about it. [Note also that I've only sent this note to the autoconf list in order to reduce duplication.] Mine came from Amazon in the post yesterday;) ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: desktop schemas review [was: Re: GSettings migration status]
Alexander Larsson wrote: On Sat, 2010-07-03 at 13:25 -0400, Ryan Lortie wrote: On Sat, 2010-07-03 at 13:37 +0200, Christian Persch wrote: This is a common error. Filenames need to be stored as ay and *NOT* s (since s is UTF-8). (I think this needs some enhancement in glib-compile-schemas to be able to still put a string in default.) I'm not sure I buy into your hardline stance on this one. I think it's not unreasonable to require that all filenames specified in the settings be in a valid encoding (whatever that encoding is) on their own filesystem (where in a valid encoding means converts correctly to and from unicode). In that case, utf8 is appropriate here. This is not right at all. Anything that does that is broken for two reasons: 1) Technically for unix all filenames are valid if they are byte strings without the characters zero and '/'. If you enforce anything else on your filenames there *will* be actual files on the system that you can't store references too. I've fixed soo many bugs from people thinking filenames are utf8 strings, they are just not, they are byte arrays. This sucks, but its reality and we have to handle it. 2) Storing a converted pathname (for instance from filename encoding to utf8) is a bad idea, even if it succeeds. First of all, the encoding is runtime dependent (env vars) so may change over time, secondly roundtripping to unicode and back does not necessarily get you the same exact bytes back, so you might not be able to actually open the file. I've spent lots of work getting this right in e.g. gvfs, where raw filenames are G_FILE_ATTRIBUTE_TYPE_BYTE_STRING, but e.g. standard::display-name is G_FILE_ATTRIBUTE_TYPE_STRING. Please don't break this. Filenames are not unicode strings, they are byte array identifiers. Given that users may store file names in arbitrary encodings, what is the best way to determine the encoding for display in a file viewer? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Fullscreen windows - weird behaviour
Andreas Falkenhahn wrote: Andreas Falkenhahn wrote: Hi, I have the following setup: ... Anybody got a clue what's going on there? You could add test code that uses XQueryTree() to find out why. http://tronche.com/gui/x/xlib/window-information/XQueryTree.html Hmm, I'm not sure if this would help. What is really confusing me is the fact that even when I call XGrabPointer() on my main window (mode set to GrabModeAsync), I can still get the task bar to pop up. How can this happen? Isn't XGrabPointer() supposed to intercept delivery of all mouse events excepting the window specified in XGrabPointer()? When I call XGrabPointer() without changing the screen mode using XF86VidModeSwitchToMode() it works exactly like that: Everything on the desktop except my window seems frozen. Clicking on the taskbar doesn't trigger any action. It's completely dead. However, when calling XGrabPointer() after XF86VidModeSwitchToMode(), it's possible to pop the task bar to the front. It's pretty weird because I thought that after XGrabPointer() the mouse would be completely mine until I call XUngrabPointer(). Does XGrabPointer() return GrabSuccess? It won't if something else has grabbed it. http://tronche.com/gui/x/xlib/input/XGrabPointer.html ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: gEDA-user: A little puzzled about the purpose of gschem
Gene Heskett wrote: On Wednesday 28 April 2010, Dave McGuire wrote: On Apr 28, 2010, at 3:40 PM, John Doty wrote: Well, you started out complaining about a 741 model. I'd call that a very rare, obsolete part: I haven't actually seen one in a circuit in over 30 years. I guess it's still in textbooks (read Stephen J. Gould's rants about textbook authors' tendency to copy from previous textbooks sometime), but why would anyone use it in a new design? Very rare?! I see 741s everywhere. WTF? -Dave Sorry to bust the bubble, but he's right. The 741 is well over 40 years old, and its open loop first response pole, where the 6db per octave rolloff begins, is a measly 10 hertz. The opamp is 1MHz unity BW. The higher the gain, the lower the first pole. An even better opamp would roll off at 1Hz. Today there are $1.00 opamps with a working gain of 20 when feedback is applied, with output slew rates of several thousand volts per second. Thats working bandwidth to several hundred megahertz at the sort of levels found in either a modern broadcast audio mixer, or a production video switcher, and either of those are driving 60 ohms for audio, or 75 for video. Those are video buffers. They have much less closed-loop gain and inferior offset voltages. They're also noisy and are very prone to oscillation with any stray capacitance or with certain feedback resistors. Slew rate limits alone in the 741 means you can't honestly ask it for more than a volt of output at full audio bandwidth. dV/dt = 2.pi.Vm at 20kHz and 1V/us, Vm=8Vpk quite ok for most apps below 5Vpk. At 3 volts the slew rate distortion is so bad even these 75 year old ears can hear it. Even a TLO-72 or 74 can mop the floor with a 741, and output a +- 15 volt rail to rail signal doing it, but into the old 600 ohm std load. LM741 has 1mV OS typical. TL072 is 3mV LM741 would be better than TL072 for control apps, and cheaper. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: Building prog first
Steffen Dettmer wrote:
On Mon, Mar 22, 2010 at 4:44 PM, Reuben Thomas r...@sc3d.org wrote:
Not true. automake does not have explicit support for building
programs with the host compiler when cross-compiling, but I
have done this successfully in the past when I needed precisely
to build a program on the host when cross compiling, using
binutils's BFD_CC_FOR_BUILD macro. It's a pity some version of
this macro isn't in autoconf, or even autoconf-archive; I shall
do the latter.
I guess this is a hack and a burden to maintain.
When cross-compiling, why compiling a local tool?
Isn't the correct way to natively compile the local tool,
then use it to cross-compile the package?
This illustrates a weirdness of autotools: poor support for
installing interpreted languages, and also conversely for
build-time compiled programs.
Yes, also for coffee-cooking there is poor support only. :-)
I don't think build-time compiled C programs shall be suppored
while cross compiling. I think it already is complex enough.
Otherwise you had to do all checks twice and end up in many
variables with confusing names, and those who are not
cross-compiling probably accidently will mix them.
I though of perl, but (A), i don't like slow tools,
(I think Perl is fast)
(C), i find making build-programs
in C much more concise than scripting and i can debug it in ddd/gdb.
You can debug Perl in DDD.
This is interesting, as it doesn't match mine or
commonly-reported experience (translating my build-time
programs from C to Perl made them shorter, easier to read and
fix, and no slower to run, although I wasn't doing more than
grepping 15k lines of C and writing some of it back out again).
$ time perl -e \
'for($n=0;$n45;$n++) { printf %08d %60s EOL\n, $n, ; }' x
real0m0.713s
$ cat x.c
#include stdio.h
int main(void)
{
int n;
for(n=0; n45;n++) {
printf(%08d %60s EOL\n, n, );
}
return 0;
}
$ time make x
gcc -Wall -Wmissing-prototypes -fstrict-aliasing -D_GNU_SOURCE -ansi
-ggdb -ggdb x.c -o x
real0m0.076s
$ time ./xx2
real0m0.301s
so 713ms vs. 377 ms.
Interesting that up to around 100k Perl is even faster:
$ time perl \
-e 'for($n=0;$n10;$n++) { printf %08d %60s EOL\n, $n, ; }' x
real0m0.167s
$ time make x
real0m0.081s
$ time ./xx2
real0m0.079s
(of course those figures are far away from being exact; they just prove
how fast perl is: same magnitude as C)
Hi,
I'd think that printf() in perl would be mapped to the same printf()
in C lib stdio, and because this is the dominant code, the times are
similar.
What i had in mind is the efficiency of regular expression execution
in perl, compared to hard-coded parsing in C.
I will try perl in ddd/gdb some time.
Re: Building prog first
Steffen Dettmer wrote: * On Sun, Mar 21, 2010 at 10:27 AM, Ralf Wildenhues wrote: noinst_PROGRAMS = unimain unimain_SOURCES = unimain.c unidata.tab.c: unimain$(EXEEXT) /usr/share/unicode/UnicodeData.txt ./unimain$(EXEEXT) $ $@ BTW, execution of built programs like this makes your package unsuitable for cross-compilation. Just so you're aware of that. Assuming unidata.tab.c is a C-code table containing the information from UnicodeData.txt, I think it could be better to generate it by some shell code (maybe inside the Makefile.am, saving a tool) or to use perl (for the price of adding perl to the build dependencies) or, if UnicodeData rarely changes, add unidata.tab.c to the package and have some `maintainer only' helper target to build it (with unidata.tab.c as distributed source file). People who don't care about unidata.tab.c can build the package even without UnicodeData.txt (if this makes any sense, I don't know what this is for of course :)) I though of perl, but (A), i don't like slow tools, (B), unidata.tab.c is 5.6MBytes and 450k lines long, (C), i find making build-programs in C much more concise than scripting and i can debug it in ddd/gdb. The size of unidata.tab.c precludes distributing it. I could do more work on compacting it, but i have already done that to a degree.
Building prog first
Hi, I want the unimain program built first, then use it to generate unidata.tab.c, which is then compiled and linked into librunicode.la bin_PROGRAMS = unimain unimain_SOURCES = unimain.c lib_LTLIBRARIES = librunicode.la librunicode_la_SOURCES = runicode.c runicode.h #nodist_librunicode_la_SOURCES = unidata.tab.c #BUILT_SOURCES = unidata.tab.c unidata.tab.c: /usr/share/unicode/UnicodeData.txt ./unimain $ $@ How do i get unimain built first? I get the error: make all-am make[1]: Entering directory `/home/russell/librunicode/src' ./unimain /usr/share/unicode/UnicodeData.txt unidata.tab.c /bin/bash: ./unimain: No such file or directory make[1]: *** [unidata.tab.c] Error 127 make[1]: Leaving directory `/home/russell/librunicode/src' make: *** [all] Error 2
Re: Building prog first
Ralf Wildenhues wrote: Hello Russell, * Russell Shaw wrote on Sun, Mar 21, 2010 at 07:06:00AM CET: I want the unimain program built first, then use it to generate unidata.tab.c, which is then compiled and linked into librunicode.la bin_PROGRAMS = unimain unimain_SOURCES = unimain.c unidata.tab.c: /usr/share/unicode/UnicodeData.txt ./unimain $ $@ Then you need a dependency from unidata.tab.c on unimain: unidata.tab.c: unimain$(EXEEXT) /usr/share/unicode/UnicodeData.txt ./unimain$(EXEEXT) $ $@ Furthermore, please don't hard-code absolute paths like /usr/share/unicode/UnicodeData.txt in your makefiles. Make them configurable by configure. Maybe your users don't have root rights on their system but have the file installed below their home somewhere? Ok. I did: AC_CHECK_FILE([/usr/share/unicode/UnicodeData.txt], [], []) In configure, i get: if test x$ac_cv_file__usr_share_unicode_UnicodeData_txt = xyes; then : fi Shouldn't this be: if test x$ac_cv_file__usr_share_unicode_UnicodeData_txt = xyes; then : fi
Re: Building prog first
Ralf Wildenhues wrote: * Russell Shaw wrote on Sun, Mar 21, 2010 at 09:26:44AM CET: Ralf Wildenhues wrote: * Russell Shaw wrote on Sun, Mar 21, 2010 at 07:06:00AM CET: bin_PROGRAMS = unimain unimain_SOURCES = unimain.c unidata.tab.c: unimain$(EXEEXT) /usr/share/unicode/UnicodeData.txt ./unimain$(EXEEXT) $ $@ Ok, that works thanks:) However, make install installs unimain into /usr/local/bin How do i stop this program from being installed? Use noinst_PROGRAMS instead of bin_PROGRAMS. Be encouraged to read the fine manual. But it is somewhat big, and i had already searched through the online one a lot first. It is no wonder it takes noobs so long to get productive. BTW, execution of built programs like this makes your package unsuitable for cross-compilation. Just so you're aware of that. Ok. I assume then that you can't build the tool for the host system while the generated files are compiled for the target system?
Re: Building prog first
Ralf Wildenhues wrote: * Russell Shaw wrote on Sun, Mar 21, 2010 at 11:18:03AM CET: Ralf Wildenhues wrote: Use noinst_PROGRAMS instead of bin_PROGRAMS. Be encouraged to read the fine manual. But it is somewhat big, and i had already searched through the online one a lot first. It is no wonder it takes noobs so long to get productive. I'm not sure how to help that. If more documentation makes people less likely to look at it, then what would you suggest in order to improve upon the situation? Is the documentation not structured well enough? Does the Autotools Introduction chapter in the Automake manual not help get a basic grasp? I agree that the initial learning steps may not be easy for Automake, but I don't see how to make Automake a lot easier without also ripping out much of the functionality. So turning that knob is fairly unlikely. Hi, I was limping along for years learning autoconf/make in bits until this tutorial came out Autotools: a practitioner's guide to Autoconf, Automake and Libtool http://www.freesoftwaremagazine.com/books/autotools_a_guide_to_autoconf_automake_libtool I realized a lot of useful things after that. The main thing that makes it easy is that a real project is stepped through with lots of side discussions, and high-level overviews put things in to perspective. I'd really like to have a hard-copy book of that tutorial. After that, i could understand the autoconf manual. I was on dos/windows up to nearly yr2000 or so, so i had to learn unix programming, shell programming, make-file programming, m4, how unix processes work etc, to be able to look in generated Makefiles and configure and see from that what errors i was making in configure.ac and automake.am. Learning too many things simultaneously, but i know now. BTW, execution of built programs like this makes your package unsuitable for cross-compilation. Just so you're aware of that. Ok. I assume then that you can't build the tool for the host system while the generated files are compiled for the target system? First off, allow me to clarify the nomenclature as it is used in GNU software: - the build system is the one you run configure and 'make all' on, - the host system is the one that the programs which 'make all' normally generates and installs, will run on later, - the target system does not exist. Never. Unless your package happens to be a compiler or linker (or similar). Then, the target system is the one for which your installed compiler/linker will generate code for. With that, your sentence above should have been Ok. I assume then that you can't build the tool for the build system while the generated files are compiled for the host system? Not straight-forwardly, no. Once you've got your basic package working and cross compilation support is the only thing missing, please come back and we'll explain. Ok. Thanks for the help. -- regards, Russell
Re: Building prog first
Alfred M. Szmidt wrote: Have you tried reading `(automake) Autotools Introduction'? It is part of the automake manual. Hi, I printed out all the autotools manuals and have read every page of them more than once. It was a while ago, so it's easy to forget things. Searching the online manual isn't all successful at times, but i've figured out a fair bit of it now.
autoscan
Hi, I ran autoscan and it gives: configure.ac: warning: missing AC_PROG_RANLIB wanted by: ltmain.sh:1601 So i added AC_PROG_RANLIB and ran autoreconf and now it says: autoreconf: Entering directory `.' autoreconf: configure.ac: not using Gettext autoreconf: running: aclocal -I m4 autoreconf: configure.ac: tracing autoreconf: running: libtoolize --copy libtoolize: `AC_PROG_RANLIB' is rendered obsolete by `LT_INIT' autoreconf: running: /usr/bin/autoconf autoreconf: running: /usr/bin/autoheader autoreconf: running: automake --add-missing --copy --no-force autoreconf: Leaving directory `.' checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk I'm using autoconf 2.65 ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: Problems with X.org and incompatibilities with in-house software
Richard Brown wrote: Mikhail Gusarov wrote: Twas brillig at 19:05:25 28.02.2010 UTC-05 when rbrown1...@gmail.com did gyre and gimble: RB So of these disabled, removed extensions. How many of these are RB disabled as a result of actual broken code, vs, how many are RB disabled because, we don't like how it looks? Most of them were removed because they were broken for years (literally) and nobody complained. If the extensions are removed because of broken code, i can understand, especially for the extensions which have duplicitous functionality which can be obtained by using other X11 features, i do not ask for time to expended to get broken code working. But, if the extensions are in working order, there is no reason or justification to remove them, even if their functionality is duplicated, different applications may be tied to a certain API. We dont like how it looks is not a good reason to remove extensions. Xprint, was this actually broken code, for instance. Ximage, was this broken code? XEVIE, again, was that broken code. What are you referring to by Ximage ? If the extension is broken code, dont waste your time, Im not asking you to spend time on it, we will do our best here to move off of them. But, if the extension is in working order, why not put it back in? To justify removing an extension, the extension needs to be in a broken, non working order, and that it is causing technical problems for the rest of the X system, and to require extensive reworking, and apps can implement what it needs in another way. We dont like how it looks, or we dont think people use this, are not good justifications. Since X.org officially has had all of these extensions until very recently, apparently although they may have been in a non working state, at the same time, they were not causing a problem, so I cannot see the action as being justified to remove them. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Problems with X.org and incompatibilities with in-house software
David Gerard wrote: On 1 March 2010 01:28, Richard Brown rbrown1...@gmail.com wrote: Russell Shaw wrote: What are you referring to by Ximage ? Ximage extension to the X server. It has been superceded by MIT shared memory. However, some ancient apps may still use it. It's not clear that *anyone* ever manage to use it successfully. http://en.wikipedia.org/wiki/X_Image_Extension Interesting http://web.archive.org/web/20080413140042/http://people.freedesktop.org/~jg/roadmap.html#mozTocId778727 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Remarks on gtk docs
Ed James wrote: Joost, and others, I tried learning to use gtk, gdk, cairo, pango, etc several years ago and was frustrated by the difficulty in getting good docs, sample code, etc. Even worse was finding that constant change meant me having to rewrite code fairly often. Note that I'm an old guy who has written code for a living since I was a young guy. But this has been the most difficult venue in which I've tried to work. I feel and share your pain in producing something of quality and lasting value. I know it can be done, but I pretty much work alone, and it's not easy. I switched to writing my own set of widgets in C++ which more or less look and act somewhat like Java's AWT, but nowhere near as powerful yet. I've got simple projects like a telnet client working, but I feel like I'm mining gold with a fork. My one big question to this list is (and no disrespect is meant), is there a elist similar to this one dedicated to Xlib programming? This list does have many very talented people, some of whom I'm in awe of. But I'm veering into a different direction and just need pointer towards that direction. ... xorg would be as close as any: xorg mailing list x...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Dual-head config broke with update to 1.4.2
Martin Cracauer wrote: ... Anyway... I will also spend some time this week to test the available Window managers to see where they stand wrt xrandr and report back. I noticed that fvwm2 seems broken enough to not even get keyboard focus over to the added desktops, ever. I also don't plan to go devhead GNOME or something like that. E17 I will build if anybody please tells me it is more xrandr aware than E16. I want to make sure that people understand that if there is a WM available that does xrandr with virtual desktops, has a purely file based configuration option and doesn't miss too much functionality I need I will happily switch to xrandr. It's not that I don't stand in front of a projector every now and then and curse that I have to start a second X11 server and can't move my clients between the two. On my todo list is to make a window manager where any application can be set to be mapped only in a specific area of a screen. This is so i can simulate dual-screen operation on a laptop screen. It will be a while before i get around to it. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X11 fullscreen
David Bronaugh wrote: Russell Shaw wrote: *SNIP* You have plenty of time on your hands, don't you? This can mean only one thing: You have an idea to sell, in the hopes that people will jump on board and run with it and you won't have to do any work. I hate to disappoint you, but it doesn't work that way. Ha, no work you say? I need no one elses work, nor do i need to sell anything. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Remote X
Hi, Is remote execution of X clients away from the X server still regarded as a design goal, or does everyone just develop for client applications that only run on or close to the X server machine? With a unicode text widget, every time a character is entered, the line or paragraph(s) need to be moved and/or reshaped. This can mean sending a few largish bitmaps for every key press. Other toolkits may add new polygon tesselated glyphs to the XRender cache: http://www.keithp.com/~keithp/talks/usenix2001/ http://cgit.freedesktop.org/xorg/proto/renderproto/plain/renderproto.txt With a cursive font, all the cursive glyphs on a line could compress when the line is close to full, but before the need for a linebreak. That would stress out the cache advantage of XRender. Another problem with XRender is that it's computationally expensive for small systems without polygon hardware. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Remote X
Patrick O'Donnell wrote: Date: Wed, 03 Feb 2010 01:18:01 +1100 From: Russell Shaw rjs...@netspace.net.au User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20091109) Sender: xorg-boun...@lists.freedesktop.org Is remote execution of X clients away from the X server still regarded as a design goal, or does everyone just develop for client applications that only run on or close to the X server machine? I sure hope it is. I typically run X clients on a variety of machines close and far. It's one of the reasons I like (and depend on) X. At the moment I have windows open on six different machines: the local workstation, one on a LAN, four over a VPN to a data center. Three of the latter display at least in part by transferring pixmap data. Network round-trip latency to the data center is about 20-23 ms at the moment. Ok. I will keep it as a priority. Other widget toolkits can be pretty slow over networks i have found. I've wondered if they even bother thinking about performance over networks. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X11 fullscreen
Daniel Stone wrote: On Sat, Jan 30, 2010 at 12:04:41AM +1100, Russell Shaw wrote: Daniel Stone wrote: On Fri, Jan 29, 2010 at 10:53:11AM +1100, Russell Shaw wrote: One can make their own widget libraries based on Xlib, then write apps using the libraries. Nothing hard about that (hard is relative;) It's not 'hard' in the sense of being groundbreaking CS research, no, but it would take an immense amount of time to get non-Western scripts (including bidi), accessibility, copy paste, full ICCCM compliance including doing the right thing with EWMH, input (including input methods), selections, etc working properly and correctly. Oh, and your app doesn't look anything like any other app now. All that is done to a degree. Theming engine allows apps to look and act like any other system. Once you architect the full depth of the problem with minimal things that work at every stage, you can add more parallelable features whenever required. OK, sounds like it should be pretty easy for you to knock up? It works, but needs refining. I shouldn't use Theming engine. That's a programmer wankword for some kind of state machine. I do theming with a simple plugin api. Ooh yeah, and your app has no concept of double-clicking. You could reimplement it and have it be completely different to the rest of the system (different maximum time between clicks, different maximum distance between click positions, etc) if you like. All the little stuff like this really does add up. Would you like a ctrl-shift+triple-middle-click popup menu? I only make useability different if i know it's the right thing to do. No, I just want double-clicking to work. It works. Please, please, stop telling people to write their own toolkits; it's quite possibly the worst advice I've ever heard on this list, to be honest. I didn't say it would be unconditionally easy, but to solve an immediate engineering problem of drawing to a full screen and having a menu, Xlib + OpenGL + Glut is fairly easy. I assume their requirements will eventually run deeper than 'full screen, one menu'. Progressing on from that and creating new widgets is useful innovation that can solve many more problems. No, it's not useful innovation at all. Why? Try scrolling a list with 1e6 elements with ease. All the answers to do anything you want is available on the web, email lists, and in books. It's definitely not quick and easy to do the whole thing. No, hence why someone asking how to do something eye-wateringly simple, we should recommend they use existing toolkits. All the answers exist, but any low-grade resource needs searching and refining. That's why toolkits exist. All the answers in one spot. Sometimes they're not suitable answers. I wouldn't be recommending any of this if i found existing widget toolkits easy to make new non-trivial widgets that run well. I've battled widget toolkits since Windows95. The code for various existing X toolkits is inpenetrable, and made overly complex for porting to non-X systems that i don't require. Having thought through many problems, these codebases can be more comprehensible, but what's the use when one has had to figure out how to make a toolkit in order to figure out how to fix one? He doesn't want non-trivial widgets, he wants full-screen and a menu, remember? That's not something that requires fixing a toolkit. I suggested avoiding full toolkits and use glut. The rest just got out of hand. I originally went to just use a toolkit when i wanted to make a simple cad program. That didn't get me anywhere useful. I don't suggest the usual toolkits for anything non-trivial, and that needs some amount of speed such as drawing or dragging objects with a mouse. Qt may be useable for anyone that tolerates C++. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X11 fullscreen
Clemens Eisserer wrote: Man, don't have a job? Is your time worth anything to you? And by the way ... I've never read so many *strange* arguments in one discussion. (using shm ximage for normal drawing is bullshit) What do you suggest? I'd very much like to know. How do other toolkits draw widgets? I haven't bothered looking for a long time. I have found no performance problems with shm ximage for the way i use it. The results look no different to any other toolkit. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X11 fullscreen
Russell Shaw wrote: Daniel Stone wrote: On Sat, Jan 30, 2010 at 12:04:41AM +1100, Russell Shaw wrote: Daniel Stone wrote: On Fri, Jan 29, 2010 at 10:53:11AM +1100, Russell Shaw wrote: ... He doesn't want non-trivial widgets, he wants full-screen and a menu, remember? That's not something that requires fixing a toolkit. I suggested avoiding full toolkits and use glut. The rest just got out of hand. I originally went to just use a toolkit when i wanted to make a simple cad program. That didn't get me anywhere useful. I don't suggest the usual toolkits for anything non-trivial, and that needs some amount of speed such as drawing or dragging objects with a mouse. Qt may be useable for anyone that tolerates C++. Cairo in gtk may be useable to a degree. I still see reports of speed problems. It is too high-level for me. It has an advantage of drawing to multiple contexts such as a printer or pdf etc. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X11 fullscreen
Clemens Eisserer wrote: Man, don't have a job? Is your time worth anything to you? And by the way ... I've never read so many *strange* arguments in one discussion. (using shm ximage for normal drawing is bullshit) What do you suggest? I'd very much like to know. How do other toolkits draw widgets? I haven't bothered looking for a long time. I tried and battled XRender for some time. It was poorly documented to the point that it hardly seems like it was intended to be used by anyone generally. It also had bugs when i used it. Gtk uses it iirc, but i won't touch it now. I did read the source in X server. Glitz and other stuff wasn't a lot of use. I just use opengl if i need much acceleration. I have found no performance problems with shm ximage for the way i use it. The results look no different to any other toolkit. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X11 fullscreen
Daniel Stone wrote: On Sat, Jan 30, 2010 at 12:13:23AM +1100, Russell Shaw wrote: This means abstracting everything with pointer indirections leading to slow Any performance problems you may have are not caused by excessive pointer dereferences. Not directly. In the context of widget kits, pointer dereferences often hide from the programmer what low level function is being called, especially when there's multiple levels. More of a pain to understand and write code knowing it will run well (sigh broken record). feature-bare toolkits. Which features are you missing from current toolkits? Foolproof multithreading. I should be able to easily have two windows being updated from different threads without interaction problems due to static vars in the toolkit. Until relatively recently, various toolkits had no kind of centralized hot-button help system that i could find. It's way too hard to make a new non-trivial widget when it should be much easier. Many widgets have performance problems when you want to scroll through 10k items from a database. I'm sure they can be made to work well with enough detailed knowledge of the widget, but to get that far, i had to figure out how widgets and everything should work because of lack of know how and documentation. Makes a toolkit rather pointless when the barrier to being productive is that high. I should be able to fork and exec from within a GUI program without problems. A gui framework baggage that comes with widgets should be minor in memory cost. Last time i was using gtk, there was no definitive way of parsing configuration files (tho there is now i think). I wanted ligatures and proper kerning in fonts. I wanted access to all the features in a truetype font file. Last i looked, pango had little documentation about using it in great or sufficient detail. Not knowing anything about non-english text, i had no hope of even knowing what to ask about pango. A simple block diagram of how it processes utf8 clusters would have gone a *long* way. Some explanation of what's in a font file and what contextual analysis is would have helped a lot. I wanted more control over hints for the window manager. That may have already existed, but there was no overview documentation in gtk about that years ago when i used it. I had to learn all the fine details of Xlib and icccm just to figure out what questions to ask. I wanted printer support. I know now that's rather vague and out of scope for widgets. There were no gtk docs explaining that. I used to be using the printer GDI in windows. There was no support for widget settings persistance, or docs saying what to do about it. If i last used a file dialog on a certain directory, i wanted it to open there next time i used the program. I know what i should do in my own way now. There was no drawing support in gtk other than gdk which i found over a year later was xlib calls. Ran slow as hell. Could use cairo now, but i stick closer to the metal and use opengl or shm images. Cairo can draw to a printer context iirc, but i'd rather just generate postscript output directly. I wanted to have accurate colour management, but i see that as out of scope of widgets now. I wanted to programmatically generate menus on the fly that adapt to the results of database retrieval based on ealier stages of the menu hierarchy. At some point gtk changed to XML files to define menus. That totally pissed me off and was when i abandoned gtk. I wanted to do window-in-window mdi. Any mention leads to howls of denial that you don't need it or it's unuseable because you can't use the app on a dual-head setup. Well, i wanted to just a drag an embedded mdi document with a mouse so that it magically becomes a top-level window. Likewise, i could drag it over the mdi container and it would become re-embedded and managed by the mdi window manager. I wanted to have a widget that acts as a window manager complete with icon handling. Then i could use a family of related applications within that shell widget, and have them all appear there in the same state next time i log on. I wanted to make independent X apps such as editors become embedded in my own widgets. I still think about that area. I wanted the whole thing to run well on a 10MHz 8-bit cpu. It still would if i omit scaleable shaded 3D buttons and do another suitable small windowing system. Memory limits for a full unicode font and various window buffers would be pushing it a bit. I still aim for that efficiency. I've read the qt book and tried qt and read the stroustrop book multiple times and know everything about C++ but remain unimpressed at the complexity of C++ toolkit code compared to the results achieved. I find C++ harder to understand and debug compared to C. Gdb had problems with C++. GObject was unsufficiently documented to achieve a full working knowledge of what it is doing. I might be able to figure that out now, but i still find the rest of gtk too tedious to use in C
Re: X11 fullscreen
Daniel Stone wrote: On Thu, Jan 28, 2010 at 10:41:04PM +1100, Russell Shaw wrote: Forget widget toolkits. They're totally lame wrappers that hide all the useful functionality from you, run like a waterlogged sheep, and otherwise assume you don't want to get anything really nontrivial running this month. You should read up on Xlib and OpenGL programming. This may not be quick or easy, depending on background, but is worth it if you have ongoing use for it. If you ignore any advice this year, please make it this. And your point is? Too hard? ;) ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
