How can you implement the C language with DrRacket? - c

Does anyone know how to install the C language or enable it in the DrRacket?
I have installed the C package but I get an error every time I run my program.
The error is:
..\..\Program Files\Racket\collects\racket\system.rkt:181:19:
system*: contract violation
expected: path-string? given: #f

First off: I'm assuming that you're talking about Jay McCarthy's "C" package for Racket. If not, please ignore everything below.
I'm pretty sure that the problem here is that you're running this on Windows. This language level tries to run a C compiler, and Windows is ... not a system that makes it easy to run a C compiler.
I think the right answer here, sadly, is that I wouldn't expect this package to work correctly on Windows. I think the best fix is probably just for the package to signal an error on Windows.
Sorry :(.
Perhaps +jeapostrophe has something to add here?
EDIT: I took a look at the package source, and that's exactly what's going on. I've made a pull request that should at least improve the error message a bit.

Related

How can I resolve an issue with a github code space for C?

Hello I am new to coding I'm currently doing the Harvard cs50x course and we use a code space on GitHub for C and it is no longer loading properly. It either loads fast and I am met with a white background, all the code being normal text, and I can not type in the terminal.
Example:
Code space
If it does not load fast it will be loading for a while and I will receive this error message I am really new to programming so any help will be appreciated. Thank you
I don't know if I understood the problem correctly, but if you just want to test simple code while the course platform doesn't work properly, you can also use a free online C compiler like the one here or even download a local compiler on your machine for more sophisticated programs in the future and not be at the mercy of online platforms like CodeBlocks or Dev-C++.
Anyway, regardless of your choice, it is also recommended to contact the course team to ensure how you can proceed in the face of error on the teaching platform.
Hope you can keep up in your learning process!

Genera: Unlocking a Package

There isn't a Genera topic on stackoverflow, but I thought I'd take the chance that one of the (probably) 5 people in the world using it might be here; no harm in trying.
I've run into the situation where a few of the systems I'm working with use pretty printing, which is not implemented on Genera. I've managed to work around the problem in my own system by using the predecessor of pretty printing, XP. Looking at the code in xp-code.lisp and comparing it to that in CCL, it's clear where CCL got its pretty printing functions from.
One solution, now proving inadequate, is to have a top-level eval that does an (xp::install :package my-package) and resume from the redefinition warnings. The problem is that when one of the third-party systems is compiled, they too complain about pretty printing features that are not implemented, so I'd have to install XP in each of these other packages that want pretty printing.
What really needs to happen is for XP to be installed in the common-lisp package, because all of these other systems are going to :use :cl and expect to have a fully functional pretty printing system.
That's not so easy though; the CL package is locked and each XP symbol requires multiple confirms, and a type 'yes', to get it into the CL package. The documentation for External-only Packages and Locking suggests that:
To set up an external-only package, it can be temporarily unlocked and
then the desired set of symbols interned in it
but no where does it say how to unlock a package, and the Document Examiner isn't turning up much.
I also have to stop and wonder if I'm barking up the wrong tree. XP was written with Genera in mind, and there are conditionalisations in the code for the platform. It shouldn't be so hard to install using the install function; and I wonder if I'm missing something obvious.
Does anyone out there know how to unlock the CL package, or the proper way install XP in Genera? The included instructions for XP appear to be out of date.
I figured it out:
(zl:setf (si:pkg-locked (find-package :cl)) nil)
Then you're free to do as you please with the CL package. Note that setf without a package qualifier might be cl:setf, which is completely different from zl:setf and won't work.

Getting error while run the program in C language

Getting warning each time while run the program in C.
This is not Error this is just a Warning .
Save the file every time before you Build and Run. This is the solution to your warning.This warning happens when you edit the program and tries to run it without saving.
Also your IDE Turbo C++ is very outdated Programming environment.I recommend CodeBlocks . Code::Blocks is a free C, C++ and Fortran IDE built to meet the most demanding needs of its users. It is designed to be very extensible and fully configurable.You can download it from here.
It seems like you are running this application in some sort of emulator.
Restart the program and try running that.
It should work.
Turbo C is terribly out of date and is probably even older than you.
I suggest you to upgrade to a IDE like Code::Blocks.
If, you are a beginner I suggest you compile using GCC command line compiler.
Save the file before you run/compile your code.

GLib/GObject intercept errors / structure code for testing, reporting or debugging

Situation:
I am working on upgrading some code at my work place. The code is for a process that is based off of GMime. We currently use GMime 2.2 and I recently upgraded our code to use GMime 2.4. The proces runs just fine and doesn't crash, but I get a
GLib-GObject-CRITICAL **: g_object_unref: assertion G_IS_OBJECT (object)' failed
every now and then when the program is running.
There are times that calls to g_object_unref fails and crashes my program. I'm trying to debug this, but unfortunately the person who made this program didn't add any testing or debugging features.
I know and understand how important embedding debugging information or setting up a testing framework is, when you have to go back into old code. I know how to set this up in pure C or pure C++, but as soon as other libararies get tossed in it becomes really difficult.
My problem is:
How how do I effectively setup debug code and/or a testing system with a program that relies on GLib or GObject?
My questions are:
How can I tell what's happening in the code? Should I be listening for "signals"? How do I setup those signals?
Functions like g_object_unref return void. That being the case how do I output debugging information related to these functions?
Does a GObject have a "property/class member", I don't know the proper term for this in relation to GLib, that has error information embedded in it?
(Related, but slightly off topic) Libraries like GLib and node.js ecetera have "extensive" documentation that amounts to:
function doSomethingThatShouldBeUsefulAndUnderstoodByAnyoneWhoReadsThis(WYSIWYG, FIY, BYOF, X, Y, Z) // this function does something that should be usefull and understood by anyone who reads the function this does something and can be called
How does one has a lot of programming experience (with languages in their pure form), go about making heads or tails of the library when most tutorials refer you back to the documents or are the documents themselves?
Is there a recommended tutorial for this?
Sites I have looked at:
http://arunchaganty.wordpress.com/2008/05/18/i-am-a-gobject/
create and emit gtk signal
https://developer.gnome.org/glib/2.28/glib-running.html
https://developer.gnome.org/gtk-tutorial/2.90/a2901.html
https://developer.gnome.org/gobject/unstable/gobject-Signals.html
Any and all comments, questions and suggestions are greatly appreciated!
Thank you.
The easiest way I know of to debug issues like this is to run the program under a debugger and break on g_logv (that error message was printed with g_logv) and when the debugger catches a call to g_logv, you can get a backtrace to see where in your program you are.
Usually these types of errors happen when a programmer tries to call g_object_unref() on a NULL pointer.
That said, is there a reason you only upgraded to GMime 2.4 instead of GMime 2.6? 2.6 has been out for several years now and is the series that is best maintained.

Setting up Spotify-API-server

I'm trying to generate spotify playlists (not text-based) and found this on Github: https://github.com/liesen/spotify-api-server
I have no experience in C programming so i don't really know where to start. Are there any relevant tutorials/articles on setting up a c-server similar to the one i'm trying to set up? on a pretty basic level.
I have a sneaking suspicion that building and using this C program isn't actually what you want (http://developer.spotify.com/en/spotify-apps-api/overview/ might be easier for you to get started with), but I'm going to help you anyway.
Most C projects have a README file that tells you how to build them. In this case, it says:
Make sure you have the required libraries
libspotify > 9
subversion (libsvn-dev) and its dependency, libapr
libevent >= 2.0
jansson >= 2.0
Update account.c with your credentials. A Spotify premium account is necessary.
Copy appkey.c into the directory and run make.
There are a few extra things that the README doesn't say, that an experienced developer will be able to guess at:
libsvn-dev and libapr are the names of Ubuntu packages (I think), so it is probably expecting your development machine to be running Ubuntu. You should probably install build-essentials as well (on a new machine, I would usually run apt-get install ${*-dev-packagages} and then apt-get build-dep ${*-dev-packages}. build-dep might download some packages that you don't need, but bandwidth is cheap, and debugging missing packages is a pain in the ass.
when it says libspotify > 9 it normally means "greater than 9 but less than 10" (if the first number in a C-library version number changes, it normally means "BEWARE: we broke things."). If you get build errors about wrong number of arguments to functions, this is probably why.
It says "run make" so there will be a file called Makefile somewhere. You need to cd into the directory that contains Makefile before typing make
make will probably produce an executable file somewhere. I usually find these by running ls and looking for items highlighted in green. If I can't find anything that way, I will read Makefile and note that "all" depends on "server" so I would look for an executable called "server".
You are jumping in at the deep end here (building someone else's experimental package as your first C program). If you get errors that you don't understand, it's not because you're stupid: it's because C is a brutal and archaic language, and it wasn't designed as a teaching language like Python was, or a beginner-friendly language like Javascript. Once you get used to it, you start to see steamtrain-like beauty of the language; the pain subsides to a dull ache, but it never truly goes away.

Resources