Recherche avancée

Sur d’autres sites (8124)

• WARN : Tried to pass invalid video frame, marking as broken : Your frame has data type int64, but we require uint8

  5 septembre 2019, par Tavo Diaz

  I am doing some Udemy AI courses and came across with one that "teaches" a bidimensional cheetah how to walk. I was doing the exercises on my computer, but it takes too much time. I decided to use Google Cloud to run the code and see the results some hours after. Nevertheless, when I run the code I get the following error " WARN : Tried to pass
  invalid video frame, marking as broken : Your frame has data type int64, but we require uint8 (i.e. RGB values from 0-255)".

  After the code is executed, I see into the folder and I don’t see any videos (just the meta info).

  Some more info (if it helps) :
  I have a 1 CPU (4g), SSD Ubuntu 16.04 LTS

  I have not tried anything yet to solve it because I don´t know what to try. Im looking for solutions on the web, but nothing I could try.

  This is the code

  import os 
  
  import numpy as np
  
  import gym
  
  from gym import wrappers
  
  import pybullet_envs
  
  
  
  
  
  class Hp():
  
      def __init__(self):
  
          self.nb_steps = 1000
  
          self.episode_lenght =   1000
  
          self.learning_rate = 0.02
  
          self.nb_directions = 32
  
          self.nb_best_directions = 32
  
          assert self.nb_best_directions <= self.nb_directions
  
          self.noise = 0.03
  
          self.seed = 1
  
          self.env_name = 'HalfCheetahBulletEnv-v0'
  
  
  
  
  
  class Normalizer():
  
      def __init__(self, nb_inputs):
  
          self.n = np.zeros(nb_inputs)
  
          self.mean = np.zeros(nb_inputs)
  
          self.mean_diff = np.zeros(nb_inputs)
  
          self.var = np.zeros(nb_inputs)
  
  
  
      def observe(self, x):
  
          self.n += 1.
  
          last_mean = self.mean.copy()
  
          self.mean += (x - self.mean) / self.n
  
          #abajo es el online numerator update
  
          self.mean_diff += (x - last_mean) * (x - self.mean)
  
          #abajo online computation de la varianza
  
          self.var = (self.mean_diff / self.n).clip(min = 1e-2)  
  
  
  
      def normalize(self, inputs):
  
          obs_mean = self.mean
  
          obs_std = np.sqrt(self.var)
  
          return (inputs - obs_mean) / obs_std
  
  
  
  class Policy():
  
      def __init__(self, input_size, output_size):
  
          self.theta = np.zeros((output_size, input_size))
  
  
  
      def evaluate(self, input, delta = None, direction = None):
  
          if direction is None:
  
              return self.theta.dot(input)
  
          elif direction == 'positive':
  
              return (self.theta + hp.noise * delta).dot(input)
  
          else:
  
              return (self.theta - hp.noise * delta).dot(input)
  
  
  
      def sample_deltas(self):
  
          return [np.random.randn(*self.theta.shape) for _ in range(hp.nb_directions)]
  
  
  
      def update (self, rollouts, sigma_r):
  
          step = np.zeros(self.theta.shape)
  
          for r_pos, r_neg, d in rollouts:
  
              step += (r_pos - r_neg) * d
  
          self.theta += hp.learning_rate / (hp.nb_best_directions * sigma_r) * step
  
  
  
  
  
  def explore(env, normalizer, policy, direction = None, delta = None):
  
      state = env.reset()
  
      done = False
  
      num_plays = 0.
  
      #abajo puede ser promedio de las rewards
  
      sum_rewards = 0
  
      while not done and num_plays < hp.episode_lenght:
  
          normalizer.observe(state)
  
          state = normalizer.normalize(state)
  
          action = policy.evaluate(state, delta, direction)
  
          state, reward, done, _ = env.step(action)
  
          reward = max(min(reward, 1), -1)
  
          #abajo sería poner un promedio
  
          sum_rewards += reward
  
          num_plays += 1
  
      return sum_rewards
  
  
  
  def train (env, policy, normalizer, hp):
  
      for step in range(hp.nb_steps):
  
          #iniciar las perturbaciones deltas y los rewards positivos/negativos
  
          deltas = policy.sample_deltas()
  
          positive_rewards = [0] * hp.nb_directions
  
          negative_rewards = [0] * hp.nb_directions
  
          #sacar las rewards en la dirección positiva
  
          for k in range(hp.nb_directions):
  
              positive_rewards[k] = explore(env, normalizer, policy, direction = 'positive', delta = deltas[k])
  
          #sacar las rewards en dirección negativo
  
          for k in range(hp.nb_directions):
  
              negative_rewards[k] = explore(env, normalizer, policy, direction = 'negative', delta = deltas[k])
  
          #sacar todas las rewards para sacar la desvest
  
          all_rewards = np.array(positive_rewards + negative_rewards)
  
          sigma_r = all_rewards.std()
  
          #acomodar los rollauts por el max (r_pos, r_neg) y seleccionar la mejor dirección
  
          scores = {k:max(r_pos, r_neg) for k, (r_pos, r_neg) in enumerate(zip(positive_rewards, negative_rewards))}
  
          order = sorted(scores.keys(), key = lambda x:scores[x])[:hp.nb_best_directions]
  
          rollouts = [(positive_rewards[k], negative_rewards[k], deltas[k]) for k in order]
  
          #actualizar policy
  
          policy.update (rollouts, sigma_r)
  
          #poner el final reward del policy luego del update
  
          reward_evaluation = explore (env, normalizer, policy)
  
          print('Paso: ', step, 'Lejania: ', reward_evaluation)
  
  
  
  def mkdir(base, name):
  
      path = os.path.join(base, name)
  
      if not os.path.exists(path):
  
          os.makedirs(path)
  
      return path
  
  work_dir = mkdir('exp', 'brs')
  
  monitor_dir = mkdir(work_dir, 'monitor')
  
  
  
  hp = Hp()
  
  np.random.seed(hp.seed)
  
  env = gym.make(hp.env_name)
  
  env = wrappers.Monitor(env, monitor_dir, force = True)
  
  nb_inputs = env.observation_space.shape[0]
  
  nb_outputs = env.action_space.shape[0]
  
  policy = Policy(nb_inputs, nb_outputs)
  
  normalizer = Normalizer(nb_inputs)
  
  train(env, policy, normalizer, hp)

• Cannot play audio from a link using a Discord Bot

  2 mars 2020, par Guilhermeffable

  I’m trying to code a bot so me and my friends can hear the local radio on our Discord Server but I’m having this error.

  This is part of my code, it’s the play.js file that handles the playback stuff.

  module.exports = (client,message) => {
  
  
  
  const voiceChannel = message.member.voiceChannel;
  
  const idChannel = voiceChannel.id;
  
  
  
  console.log(idChannel)
  
      //vê se o user está numa sala de voz
  
  if(!voiceChannel) {
  
      return message.channel.send("Precisas de estar num voice channel para usar este comando.")
  
  }
  
  const permissions = voiceChannel.permissionsFor(message.client.user);
  
  
  
   //vê se tem permissões para entrar na sala
  
  if(!permissions.has('CONNECT') || !permissions.has('SPEAK')) {
  
      return message.channel.send("Não tenho permissões para entrar nessa sala.")
  
  }
  
  
  
  voiceChannel.join()
  
      .then(connection => {
  
          console.log("Successfully connected.");
  
          connection.playStream('http://centova.radios.pt:8401/stream.mp3/1')
  
  }).catch(e =>{
  
      console.error(e);
  
  
  
  });

  }

  And this is the error I’m getting :

  TypeError [ERR_INVALID_ARG_TYPE]: The "file" argument must be of type string. Received an instance of         
  
  Object
  
  at validateString (internal/validators.js:117:11)
  
  at normalizeSpawnArguments (child_process.js:406:3)
  
  at Object.spawn (child_process.js:542:16)
  
  at new FfmpegProcess (C:\Users\guilh\desktop\BOT\orbitalbot\node_modules\prism-media\src\transcoders\ffmpeg\FfmpegProcess.js:14:33)
  
  at FfmpegTranscoder.transcode (C:\Users\guilh\desktop\BOT\orbitalbot\node_modules\prism-media\src\transcoders\ffmpeg\Ffmpeg.js:34:18)
  
  at MediaTranscoder.transcode (C:\Users\guilh\desktop\BOT\orbitalbot\node_modules\prism-media\src\transcoders\MediaTranscoder.js:27:31)
  
  at Prism.transcode (C:\Users\guilh\desktop\BOT\orbitalbot\node_modules\prism-media\src\Prism.js:13:28)
  
  at AudioPlayer.playUnknownStream (C:\Users\guilh\desktop\BOT\orbitalbot\node_modules\discord.js\src\client\voice\player\AudioPlayer.js:97:35)
  
  at VoiceConnection.playStream (C:\Users\guilh\desktop\BOT\orbitalbot\node_modules\discord.js\src\client\voice\VoiceConnection.js:546:24)
  
  at C:\Users\guilh\desktop\BOT\orbitalbot\commands\play.js:24:24 {
  
    code: 'ERR_INVALID_ARG_TYPE'

• Anomalie #3017 : Gestion des versions de plugins

  18 avril 2020, par RastaPopoulos ♥

  Je passe ce ticket en anomalie, car il s’agit à mon sens très clairement d’un bug (et un gros) : l’ergonomie aussi peut être buguée.

  Récemment, en peu de temps, plusieurs plugins ont eu des problèmes car les utilisateurs ont eu l’invitation de migrer à la dernière version alors qu’il y avait un saut de branche majeure (le X), sans aucun message de warning nulle part : spipr, saisies, prix… Et cela occasionne clairement des gros problèmes pour les gens, et donc bien du bug. Et encore, il ne s’agissait pas de mises à jour modifiant la base de données… là impossible même de revenir en arrière.

  Je pense qu’il faut profiter de ce ticket déjà existant, pour réaffirmer que c’est un bug et réfléchir à une ergonomie cohérente quelque soit les différents endroits : liste des plugins et icône-bouton d’annonce de mise à jour, recherche des plugins et comment on voit les différentes versions, etc.

  Je décris en texte, on verra si j’ai le temps de faire une maquette un jour…

  Vue des plugins actifs :¶

  C’est le cas le plus courant qui peut casser des choses chez les gens.
  - L’indication de mise à jour classique ne devrait s’afficher que pour les mises à jour Y et Z
  - Éventuellement un autre bouton différent indiquerait qu’il y a une mise à jour majeure X
  - Les mises à jour quelles qu’elles soient (mineures ou majeures) ne devraient se voir que si l’état est aussi stable ou plus stable que l’actuel (c’est déjà le cas je crois)
  - Parfois dans les releases il y a une mise à jour dans la même branche X et une autre changeant de X, dans ce cas on verrait bien deux indications et deux boutons différents
  - Une option générale de SVP pourrait permettre de choisir si on signale les mises à jour majeure ou pas (si non, seules Y et Z seront signalées)
  - Lorsqu’on choisit de mettre à jour à une version majeure supérieure, alors il devrait y avoir un méchant message ATTENTION, indiquant ce qu’on s’apprête à faire, ce qui permet d’annuler. Dans la phrase indiquant cela, il pourrait y avoir un lien vers la doc de la version majeure supérieure qu’on s’apprête à mettre. (Attention, vous allez changer la version majeure du plugin Patates en 3.3.3. Pensez à vérifier que cela ne va pas casser votre site : lien vers la doc)
  - Pour les actions de masse, pareil, ça devrait afficher les mêmes messages, mais plusieurs à la fois dans la même boite.

  Au passage : comme on le voit, parfois il est possible qu’on ait besoin d’ajouter des actions supplémentaires aux plugins. Il serait sûrement profitable de revoir une organisation cohérente des boutons comme discuté dans ce ticket : #4429 (et non pas certains en picto, certains en hover, etc). Notamment aussi car c’est toujours mieux quand on arrive à avoir des labels (d’autant plus si on doit différencier mise à jour mineure et majeure).

  Vue des plugins présents inactifs :¶

  On ne parle ici que des plugins non actifs ayant déjà une version activée (les autres on s’en fiche, ya rien à dire c’est une installation classique). Si on les a téléchargé et que c’est bien compat avec la version SPIP générale, on doit toujours les voir, seuls les obsolètes sont cachés par défaut.

  - Si dans les inactifs il y a une version supérieure mais mineure d’un plugin déjà actif, on le voit et on peut l’activer et aucun message particulier
  - S’il y a une version supérieure majeure d’un plugin déjà actif, on doit le voir aussi mais dans son cadre, il pourrait déjà y avoir une indication que ce plugin est déjà en cours d’utilisation et que cette version est un changement majeur. Et ensuite quand on essaye de l’activer, on devrait avoir le même message ATTENTION que décrit précédemment dans la boite qui s’ouvre.
  - Contrairement au premier onglet, là on doit voir aussi les versions même si l’état est moins stable (si ya un "test" alors que celui actif est "stable") : si on l’a téléchargé c’est qu’on veut le voir et pouvoir l’activer
  - On ne voit pas les versions plus petites que celles actives, car certaines plugins ont des structures de base, et là ça peut pas marcher de revenir en arrière. Celles là sont cachées si une version plus haute est active, mais on les voit si jamais installé par contre.

  Recherche des plugins :¶

  Actuellement l’interface ne montre que la dernière version, ce qui ne va pas du tout. De plus quand un plugin est déjà installé, ce plugin sort bien dans les résultats de recherche (avec "déjà installé") mais impossible de le télécharger même si la version indiquée dans la recherche est supérieure à celle en cours.

  Pour cet onglet, c’est plus que des corrections, il faudrait vraiment refaire pour voir au moins la dernière version de chaque X (voire de chaque X.Y) de chaque plugin. Que ce soit pour des plugins qu’on a pas du tout et pour des plugins déjà installés.

  Si j’ai le plugin Patates 3.13.0 installé, et qu’il a plusieurs mises à jour de plusieurs branches, alors dans la recherche je devrais voir :
  - La version 4.0.2 (avec un Attention)
  - La version 3.15.1
  - La version 3.13.4

  Si le plugin n’est pas du tout installé (et n’a jamais été installé ou a été bien désinstallé, bref : qu’il n’a plus son "base_version" du tout !) alors on devrait voir plus, et voir aussi la 2.4.5 etc, si on sait qu’on veut installer telle plus vieille version.

  On pourrait voir un bloc par plugin, et à l’intérieur, au lieu d’une seule case à cocher, sous le titre et slogan, on aurait une liste des versions, chacune avec sa case à cocher.